PoC: Move RAUC statusfile to persistent storage and check Status in release-validation post update

[yfyf]

This started out with b9143cc - after the select-display bug, I wanted to extend the tests to check that post-update the system reaches a Good state. When I tried that, I realized that does NOT happen in release-validation tests, since /boot/status.ini gets corrupted and statusfile-recovery fails. This is due FAT shenanigans to the unclean system_reset used in the test. See attached screenshots.

So this is actually 2 PRs, but I wanted to illustrate that the moving of RAUC to persistent storage kinda works already in the tests.

The actual implementation can be simplified and needs more tests/clean-up, but opening this draft so we can discuss it.

/boot/status.ini corruption in release-valdiation tests without 2414fd3

[knuton]

@yfyf After #305, should we close this PR for now?

[yfyf]

@yfyf After #305, should we close this PR for now?

Let's keep this around for/when we consider the skeleton matrix and etc? If anything, it's a useful illustrative example of what kind of problematic interactions might happen between the running system and the skeleton.

I think it's also worth considering how to deal with this issue, the approach used here could be used as a safer alternative to only having the statusfile in /boot / FAT, provides extra disaster recovery. As discussed, it could also be a different approach (e.g. recreate status file from scratch), but some approach is needed.

[yfyf]

Looking at this again with #329 about to land, I think this approach could work, especially since we pin down RAUC and deps. The benefit is that it safeguards us against FAT corruption during installs, which are bound to happen, particularly as we plan to have more standalone / at-home installations, where PlayOS is more likely to be powered on only during use.

The key idea is:

• Storing RAUC status file in the persistent data volume (/var/lib/rauc), which uses a proper journaling FS (ext4)
• Using /boot/status.ini only as a last-resort recovery storage (e.g. if persistent data is wiped or corrupted)

The tricky part is ensuring backwards compatibility with older versions. This PR handles that directly by "recovering" from /boot/status.ini if it has been updated by the other slot. This complicates the recovery logic. An alternative approach could be to do this change in stages:

• Release a PlayOS version that only mirrors the RAUC status file to /var/lib/rauc/, but still uses /boot/ as primary source
• Once all installations have progressed to write to /var/lib/rauc, we can switch to using it as the primary source and only recover if it is missing. This would simplify the recovery logic by a lot.