Store application tokens/access-keys on EEPROM

[zytegalaxy]

If we store application tokens/access-keys on file system, AND the user setups a fresh system from a new image, they will have to reconnect all services. If we store/fetch that data on EEPROM, we address this shortcoming.

We can offer an option to erase everything (factory reset) if the user wants to give their device to someone else.

EEPROM does not have read/write cycle limitations (wear and tear) but write operation is a bit slow.

[sassanh]

We basically need a file system abstraction implemented using fsspec, then we let the user choose different options for storing config and secrets (each in a separate menu) and EEPROM would be one of their options.
They can choose multiple options, if the app finds out there is a difference in stored data while starting up, it will ask the user which one it should choose.
If a user selects a new storage and it already has data and the data is different than the loaded data, it will again ask the user to choose.
We may later let the user to select in details which piece of data should come from which source when a conflict happens.

[zytegalaxy]

I suggest we limit number of writes to EEPROM to once a day; The data does not need to in high frequency sync since EEPROM is only going to hold app secrets which are going to be only a handful and entered infrequently.

We should probably have a factory reset option under Settings that wipes off this data from EEPROM. We could even add a manual backup option to let users to sync EEPROM content (backup secrets) manually by pressing a button.

[sassanh]

@zytegalaxy I think it's a good idea to limit the number of writes to the EEPROM, but maybe we need to be more flexible. A user may enter multiple secrets on their first day, or they could enter several secrets on a particular day while setting up a specific service.
So instead of limiting writes on a daily basis, I suggest limiting them to "only when a secret has changed," this might result in multiple writes on some days, but in the long run, it may be much more efficient.