fix: atomic saves for prefs, ACL, regions and companion blobs

[benallfree]

Hey guys I noticed that config writes currently truncate-then-write in place, which can risk losing prefs on a crash or failure. This PR makes those saves atomic write-rename instead.

Let me know what you think.

[liamcottle]

Unfortunately this doesn't fix the issue on nRF boards using LittleFS due to differences between file system block size and page erase sizes.

@oltaco and I spent significant time digging into the lower level stuff to resolve this, but ultimately it requires changes at the LittleFS level.

You'll find that even with atomic writes, you'll still get file system corruption, or file loss during power off due to nRF erasing more blocks than LittleFS expects.

Can be tested by saving preferences in app, and powering off the node while it's writing. Which would be a similar scenario as battery going flat while receiving/saving an advert payload to contacts database.

[oltaco]

Yep, @liamcottle is correct. The fix will be this #2964, I haven't had a single corruption with LFSv2.

[benallfree]

@liamcottle @oltaco Thank you for looking into this more. In #3012 I mentioned LFSv2 as a possible solution, it's great to learn that it is already underway.

[benallfree]

Just for clarity...this PR is not about FS corruption though. Currently there is a short window where prefs are deleted and new prefs have not been written.

Is there any value to the write-rename vs delete-write? I still see a possibility where all prefs can get lost without filesystem corruption.

[dotspencer]

I dumped the flash of a RAK4631 that lost its contacts and dissected the ExtraFS partition offline with littlefs v1 compiled for the host (assisted by claude code)

/contacts3 was present with size 0 and head 0xFFFFFFFF, and the previous directory revision had no contacts3 entry at all. The remove committed, the re-create committed, the data write never landed. No block corruption involved, so this is the window @benallfree is describing, and write-rename would have saved the file.

The same device also had block-level corruption, but in a different file: /adv_blobs had a skip-list pointer reading 0x7f80f5b5 on an 800 block partition. That one is the block size vs page erase mismatch @liamcottle and @oltaco are describing, and atomic rename would not have helped there. Both failure modes look to be independent.