feat: consume vehicle-provided parameter metadata

[JackSkellet]

Summary

This adds support for consuming parameter metadata published by the connected flight controller instead of relying exclusively on BlueOS's bundled ArduPilot metadata files.

The implementation:

• receives MAVLink COMPONENT_METADATA advertisements;
• downloads bounded parameter metadata documents over MAVFTP or HTTPS;
• validates the advertised CRC and document structure;
• exposes the active document from ArduPilot Manager with ETag support;
• merges vehicle-provided metadata over the nearest compatible bundled metadata in the frontend;
• refreshes the table when the vehicle advertises a new metadata generation;
• keeps bundled fallback selection within the same vehicle family;
• upgrades mavlink2rest from t0.11.25 to 0.11.26, adding COMPONENT_METADATA while preserving the 0.11 API.

Why

BlueOS currently assumes that parameter names, descriptions, units, ranges and enum choices are fully described by a static metadata file bundled with the frontend. That does not work well for custom firmware or for parameter choices that depend on devices discovered at runtime.

This enables use cases such as:

• custom or development firmware supplying descriptions for parameters that do not exist in an upstream ArduPilot release;
• detected sensors being presented as meaningful enum choices without a BlueOS-specific override;
• per-lane EKF source-target selection, for example selecting different DVLs for EK3_SRC1, EK3_SRC2 and EK3_SRC3;
• refreshing source-target choices when sensors are attached, removed or replaced;
• vehicle-specific parameter descriptions, units, defaults, ranges, bitmasks and enum labels;
• continuing to use bundled ArduPilot metadata when a vehicle does not publish component metadata.

The live metadata overlay has exact-name priority and also supports parameter templates. Invalid documents fail closed and do not replace the last valid snapshot.

Parameter import reliability

The parameter loader is also made tolerant of parameter files from another firmware version or feature set:

• parameters absent from the connected vehicle are skipped instead of blocking the whole import;
• PARAM_SET uses the live parameter's MAVLink type;
• rejected values stop retrying after the existing bounded retry budget and are reported as skipped;
• retry timers and state are cleaned up when the dialog completes or closes.

This allows a useful subset of a parameter file to be applied without leaving the loader permanently failed because optional parameters are unavailable.

mavlink2rest compatibility

COMPONENT_METADATA is not available through the previously pinned mavlink2rest release. Version 0.11.26 adds it through rust-mavlink 0.10.13 while preserving the existing 0.11 JSON API.

Validation

• ArduPilot Manager parameter-metadata tests: 9 passed.
• Frontend parameter-metadata tests: 8 passed.
• Targeted ESLint and Stylelint: passed.
• Ruff and Mypy checks for the changed Python paths: passed.
• Official mavlink2rest 0.11.26 artifacts resolved for x86_64, ARMv7 and AArch64.
• Live ARMv7 Raspberry Pi 4 and AArch64 Raspberry Pi 5 testing: BlueOS startup/shutdown, metadata advertisement, MAVFTP retrieval, ETag refresh, fallback selection and parameter-table rendering passed.

[CLAassistant]

All committers have signed the CLA.

[patrickelectric]

@JackSkellet can you rebase the PR over master ?

[JackSkellet]

@patrickelectric rebase has been completed.

[patrickelectric]

you should not update mavlink2rest since it breaks the api from 0.X to 1.X.

[JackSkellet]

t0.11.25 does not contain the COMPONENT_METADATA message (ID 397) required by this implementation. That message becomes available in mavlink2rest 1.0.x, but I understand that upgrading breaks the existing API. Would you prefer an API-compatible 0.x backport of message 397, or an alternative BlueOS integration path?

[patrickelectric]

The best way to workaround that, is to..
Send a PR to https://github.com/mavlink/rust-mavlink/tree/0.10 (0.10 branch), with a patch commit like this one mavlink/rust-mavlink@b0da5b2 and a update version commit like this one mavlink/rust-mavlink@b210832. After that, I will create a release.
With that done, we can then create a 0.x-dev branch to release an API compatible update mavlink2rest release.

[JackSkellet]

rust-mavlink 0.10 backport: mavlink/rust-mavlink#527

Tested on BlueOS with mavlink2rest 0.11.25; parameter metadata loads successfully.

[patrickelectric]

check: #4089

[JackSkellet]

Updated to mavlink2rest 0.11.26 and reverted the temporary 1.x compatibility handling, restoring the existing BlueOS MAVLink code paths. Parameter metadata now decodes correctly on a live BlueOS system, while the remaining message handling works as before.

[ES-Alexander]

Thanks for the contribution @JackSkellet! :D

From some internal discussion, MAVLink Server includes MAVFTP support, and using its API for that would be a preferred approach over re-implementing MAVFTP handling in the ardupilot manager service.

[ES-Alexander]

Was there a reason for this change (and the others like it)?

We generally avoid cleaning up code that we aren't already touching for other reasons, outside of occasional dedicated cleanup commits.