do not bootstrap companion rtc

[kujeger]

Bootstrapping companion RTC from contact lastmod time meant that if/when the companion clock strayed into future time because of clock drift, contacts would get a future/corrupted timestamp -- which the companion would happily restore upon reboot. And since the firmware rejects setting time backwards, it could never be fixed even when rebooting, causing the companion clock to ever drift further ahead.

Resolves #3050

[kujeger]

Tested and verified on my T114 BLE companion. With the patched firmware flashed, the android app (and meshcore-cli) was able to set the clock correctly.

[liamcottle]

While it's fresh in my mind, a side effect of not bootstrapping the clock will result in the firmware deleting the wrong contacts when you have auto overwrite oldest enabled. Tagging @oltaco as there was a reason this was implemented.

[kujeger]

Possibly a better way to resolve these issues is to allow the companion firmware's clock to be set backwards, but I'd guess that has some other implications as well (but maybe not as bad as for a repeater?)

[oltaco]

Unfortunately this would break the overwrite oldest contact feature when nodes have been restarted and haven't had their clock set yet. It would cause incoming adverts to cycle in the oldest slot instead and so you only ever get the last contact added to the list in the oldest slot.

I think allowing the companion clock to be set backwards would be the more correct fix. Allowing clock to be set backwards probably solves more problems than it creates?

[kujeger]

an alternative approach to overwriting oldest contact could be to give each contact an auto-incrementing serial whenever it gets added/updated, and simply remove the one with the lowest id when storage is full, but I'd wager that's a big rewrite 😅

[todd-herbert]

As a hotfix I've been allowing the time to move back and then updating any bad (future) lastmod times.
https://codeberg.org/todd-herbert/InkCore/commit/6ce7b5cf24368a975fccceab90718aba7b0f76eb