Feature/serial settings

[ryan-summers]

This is a proof-of-concept using the serial-settings crate to see how well it works with the API.

cc @jordens

[ryan-summers]

@jordens I had to refactor to the latest versions in Stabilizer. Mind taking a second look here?

[jordens]

I'm confused. Don't we store the main board settings (broker etc) already in the eeprom? And with this now also in flash?
Could you document somewhere the overall architecture (what's stored where in which format, what's the precedence etc)?

[ryan-summers]

I'm confused. Don't we store the main board settings (broker etc) already in the eeprom?

Correct, we did store it in EEPROM, but the EEPROM was too short to contain i.e. a DNS-named broker, so this PR is migrating existing settings over to flash.

And with this now also in flash?

The intent of the design is to:

1. Load initial settings from EEPROM (if present)
2. Update settings from any flash-based values

That way, we don't cause users to lose their existing configs when switching from earlier booster firmware to latest. However, it does result in us carrying over a bunch of legacy EEPROM code for settings management and makes the whole process more complicated.

All new settings will be written to flash and EEPROM will essentially be "frozen" after this merge.

We could just entirely deprecate the old EEPROM settings and force users to reconfigure booster during the firmware update if we want to simplify.

Could you document somewhere the overall architecture (what's stored where in which format, what's the precedence etc)?

Yeah, this is a good idea. I'll add it to one of the settings modules.

[jordens]

LGTM with these slight changes.