Better signaling for network connection

[brentru]

WipperSnapper currently hangs and resets after an unsuccessful WiFi network or MQTT connection. It's difficult for the user to understand what's occurring if they aren't paying close attention to the LEDs.

This pull request:

• Adds a maximum amount of connection attempts to the network connection and mqtt connection states
  • If the maximum attempts are exceeded, the hardware will blink red indefinitely and write the error to both the serial output and the whippersnapper boot output text file.

Addresses #165

[brentru]

@hathach I have a TinyUSB-related question about this PR and this is the best place for convo.

The code calls Wippersnapper_FS::writeErrorToBootOut which successfully opens and writes to the boot text file. I call qspi_msc_flush_cb after the file is closed in order to flush the pending cache...

  // Append error output to FS
  File bootFile = wipperFatFs.open("/wipper_boot_out.txt", FILE_WRITE);
  if (bootFile) {
    bootFile.println(str);
    bootFile.close();
    qspi_msc_flush_cb();
  } else {
    WS_DEBUG_PRINTLN("ERROR: Unable to open wipper_boot_out.txt for logging!");
  }

However, the WIPPER drive (a msc_external_flash volume) only occasionally shows an updated text file when I look at the file on the USB volume.

Is there a way to reliably force the text file to update its contents? Does the TinyUSBDevice need to be detached/attached after every write?

[hathach]

Is there a way to reliably force the text file to update its contents? Does the TinyUSBDevice need to be detached/attached after every write?

@brentru There could be a way, but I haven't tried to figure it out. It probably involves SCSI commands manipulation such as response a error sense code, then self-recover, that maybe trigger the host to re-scan the device. It needs someone with better knowledge of SCSI command to figure it out since SCSI command is very messing https://www.seagate.com/files/staticfiles/support/docs/manual/Interface%20manuals/100293068j.pdf .

[brentru]

@hathach Ok, thanks! We'll leave it for now, then.