SafeFile: use atomic rename-with-overwrite, rather than non-atomic delete-then-rename

[compumike]

Debugging the same "loses long_name, short_name" bug as #9248 led me to find that SafeFile was breaking atomic guarantees in LittleFS, creating a window of opportunity where there is no /prefs/device.proto even though it was opened with fullAtomic == true.

LittleFS promises:

Power-loss resilience - littlefs is designed to handle random power failures. All file operations have strong copy-on-write guarantees and if power is lost the filesystem will fall back to the last known good state.

[...]

All POSIX operations, such as remove and rename, are atomic, even in event of power-loss. Additionally, file updates are not actually committed to the filesystem until sync or close is called on the file.

Previously:

    FSCom.remove(filename.c_str())
    // a reset while here (or before the rename completes) would leave us with no file at filename!
    FSCom.rename(filenameTmp.c_str(), filename.c_str())

Remove-then-rename means that any reboot that takes place after the remove finishes and before the rename finishes will cause a missing /prefs/device.proto.

With this PR:

    FSCom.rename(filenameTmp.c_str(), filename.c_str())

A reboot at any time will result in either the old or the new version of /prefs/device.proto existing. That's atomic.

(Note that ARCH_NRF52 bypasses this.)

Testers wanted

Especially on non-ESP32 devices!

🤝 Attestations

• I have tested that my proposed changes behave as described.
  • Heltec (Lora32) V3