Reintroduce optional parameter versioning mechanism for airframe maintainers

[MaEtUgR]

Solved Problem

When working on multiple projects I found that many reintroduced a mechanism to allow automatically resetting the parameter configuration during a product update. This functionality was initially introduced in #11760 and removed again in #17279 because we (including me) thought that the param set-default mechanism of #16796 would solve all the cases. But the case where the airframe maintainer wants to enforce a reset to airframe defaults is not covered anymore with the param set-default mechanism. For products based on PX4 this is still required to ensure proper functionality after a major update.

Solution

I suggest to reintroduce what was removed in #17279 in a slightly adapted way.
The mechanism is still exactly the same. An airframe maintainer can optionally add e.g. an set PARAM_DEFAULTS_VER 2 line in the airframe file such that vehicles coming from an older (or newer) version airframe as detected using the SYS_PARAM_VER parameter get reset to the default configuration. As usual accumulating flight numbers, hours, RC, sensor and newly also airspeed calibration are preserved.

Changelog Entry

Feature: Reintroduce optional parameter versioning mechanism for airframe maintainers

Alternatives

I tried to work around the necessity to trigger a reboot for the mechanism but after some testing it's still the most useful way in my eyes. The parameter version is only available after loading the airframe but arch and board defaults need to be loaded before that and the reset has to be done before that even because otherwise all param set lines in these configurations would be reset again. So either we'd load the airframe twice per boot or just reboot the system if a reset is required.

Test coverage

I tested this on a vehicle which already had a parameter version from the previous mechanism and it seamlessly reset to the latest defaults even if I manually changed the parameters manually before the update.

Context

I was in discussion with @dagar about a possibly better less shotgun way to address the specific use cases solved by this mechanism but at least to me it's not clear yet how to solve all cases especially during bringups and major updates where a known working configuration is usually crucial to move multiple vehicles forward.

[dagar]

We could add something to make it easy to skip the volatile parameters.

[dagar]

How about param reset_all --skip-volatile X? Then we'd only need TC and a few other little things on top.

[MaEtUgR]

I

• rebased on main
• removed the unrelated cahnges like shortening the reset exclusion parameter name wildcards and adding the airspeed calibration to the exclusions

This pr is about the parameter versioning mechanism and not about airspeed calibration or revising the volatile parameter reset mechanism.

[sfuhrer]

Thanks for coming back to this - I agree that we have to focus on bringing the reset mechanism in here, and should move the work around which params to not reset to another PR.
I just have some proposals for cleaner comments. Otherwise looks good to me (haven't tried it out myself though).

[hamishwillee]

FYI There have been some questions in the last couple of days on discord about how parameters "change managed" across versions, following renames and deletions. Would appreciate an update to the param docs for that.

[MaEtUgR]

@sfuhrer Thanks for your suggestions, it's important to be clear 🙏 I tried to adjust the wording from what we originally had to address the valid input.

[MaEtUgR]

Rebased on main to have CI run again. The previous errors looked like the ones we fixed recently, see #23200

[sfuhrer]

69 bytes over flash on v5