Global IO feed errors propagate to WipperSnapper and cause device reset/crash

[brentru]

Describe the bug

Malformed packets being sent to non-WipperSnapper Adafruit IO feeds cause Adafruit IO to publish an error along the MQTT error feed(https://io.adafruit.com/api/docs/mqtt.html#username-errors). The WipperSnapper application WDT resets within cbErrorTopic, regardless of whether that feed pertains to it.

Arduino board Adafruit Feather Huzzah ESP32

Expected behavior Data sent by non-wippersnapper-specific Adafruit IO feeds should not interfere with WipperSnapper clients.

Which components are connected to your device None

Log

Looking for subscription len 18
Found sub #3
Data len: 88
Data: "error saving data to adafruitguy/feeds/REDACTED, data missing required value"
IO Ban Error: "error saving data to adafruitguy/feeds/REDACTED, data missing required value"
Disconnecting from MQTT..MQTT disconnect packet:
          [0xE0],   [0x00],
Client sendPacket returned: 2
E (234460) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (234460) task_wdt:  - loopTask (CPU 1)

[lorennorman]

(thought dump as i ran into this while working on the firmware tool migration)

This happens when the something sends a message to the {username}/errors MQTT topic, which is the global topic for the user accounts.

What we should at least do is make sub-topics per-device for them to subscribe to: {username}/wipper/{deviceId}/errors

...and possibly even per component? {username}/wipper/{deviceId}/{componentId}/errors

Furthermore, it would be nice to differentiate a fatal error from a non-fatal one, or tell the device what to do in some other way. Automatically rebooting is great for some kinds of problems, but awful when the result will be a reset loop. We'd like to be able to make a breaking change while also telling the device that it is useless to keep trying with its current firmware.