Mavlink compatibility patch

[xznhj8129]

WIP Extensive reworking of the MAVLink code to modernize, remove placeholder/boilerplate stuff and improve compatibility with GCS features like missions. No new Flight controller or MSP features added yet (to implement stuff like takeoff or setting altitude), that will be for a later stage.

Summary

• Expand MAVLink support to include EXTENDED_SYS_STATE stream, protocol/autopilot version replies, available/current modes, and proper vehicle type detection. VTOL state is currently UNDEFINED
• Rework mission handling to accept/send both MISSION_ITEM and MISSION_ITEM_INT with unified parsing, frame validation, and waypoint→MAV command mapping.
• Improve stream-rate control (per-stream setters, GET/SET_MESSAGE_INTERVAL, REQUEST_DATA_STREAM), and split HUD/heartbeat sending for cleaner scheduling.
• Add handling for HOME_POSITION (when GPS home is fixed) and SET_POSITION_TARGET_GLOBAL_INT as a GUIDED/GCS-nav waypoint update.
• Update ArduPilot mode enumerations to current values; factor heartbeat mode flags based on actual flight mode rather than always marking manual/stabilize.
• Timestamp GLOBAL_POSITION_INT with boot ms instead of raw usec to match MAVLink spec; include version header needed for autopilot/protocol version replies.

Details

• Added new protocol definitions: EXTENDED_SYS_STATE stream ID/rate slot (for landed/flying state), ArduPilot version constants, frame-support mask helpers, and a vehicle-type mapper used by heartbeat and mode reports.
• Stream control now uses mavlinkSetStreamRate/mavlinkStreamIntervalUs, tracks configured defaults, and drives EXT_SYS_STATE off the extra3 rate by default.
• Telemetry scheduling separates HUD and heartbeat senders so we can use either seperately, emits EXTENDED_SYS_STATE explicitly, and wires the new stream into the periodic loop.
• Modes: expanded plane/copter enums; available/current modes message support; heartbeat flags now set GUIDED/AUTO/STABILIZE based on FLM and respect manual-input gating. This is not perfect and needs real BOXID mapping.
• Mission upload/download: request INT first; shared mavlinkHandleMissionItemCommon handles frame validation and waypoint creation; fillMavlinkMissionItemFromWaypoint builds outgoing items with frame selection via altitude mode; supports JUMP/SET_POI/SET_HEAD/RTH/LAND/LOITER/WAYPOINT. We only handle global and relative altitude frames, no NED or AMSL or terrain.
• Commands: implement MAV_CMD handling for DO_REPOSITION, GET/SET_MESSAGE_INTERVAL, REQUEST_MESSAGE, REQUEST_PROTOCOL_VERSION, REQUEST_AUTOPILOT_CAPABILITIES, GET_HOME_POSITION; add ACK helper. Since COMMAND_LONG and COMMAND_INT are essentially the same thing but with just two params as ints vs floats, i united the two in a single function. INT-first request aligns with QGC; float-only GCS should still work.
• Messages: support HOME_POSITION send; process REQUEST_DATA_STREAM and SET_POSITION_TARGET_GLOBAL_INT to update WP255 when allowed.
• GLOBAL_POSITION_INT timestamp switched to ms (boot) per MAVLink field definition.

Testing

• Testing with Speedybee F405WINGMINI in X-Plane HITL with MLRS mavlink receiver, routing BLE to Mavproxy
• Using QGC and UASTOOL, it works, shows correct telemetry, can set GCS Nav, can upload and fly a simple mission
• Mavlink receiver still works
• Mostly testing with mavlink_type set to ARDUPILOT

Things in this PR that could need work

• MSP to/from MAV mission translation isn't complete, it drops MSP-only fields (leg speed, LAND ground elevation, RTH land-flag, user-action bits which is pretty bad), so we need to think about how to handle this.
• Parameter requests still aren't handled and don't return anything; questionnable if they ever should.
• Upload/download missions via MISSION_ITEM and MISSION_ITEM_INT (QGC/MP/UASTOOL) including JUMP/ROI/yaw; verify sequence/ACKs and waypoint storage.
• Verify stream-rate control: SET/GET_MESSAGE_INTERVAL, REQUEST_DATA_STREAM, and default reversion. Message interval rates could use some improvements and mapping to what streams we can actually send
• Confirm heartbeat/custom_mode and available/current modes match expected ArduPilot mappings for multirotor vs fixed-wing profiles. This is an issue right now; as the current handling of AUTOPILOT_VERSION in Ardupilot mode blocks displaying of correct custom modes and shows Unknown (except GUIDED?) when set to a real AP version (ie 4.6.3), while setting it to 0 will make QGC spam request AUTOPILOT_VERSION. This may be related to (QGC issues regarding mode display)[https://github.com/Standard modes doesn't work for 'generic' autopilot mavlink/qgroundcontrol#13472]. UAStool does not display the correct fixed wing modes, so that's a hint. May try revisiting Standard Modes eventually, but i'm clearly still doing something wrong.
• mavlinkSendAvailableModes sends all possible modes, not actual available modes; need to handle this like MSP_MODE_RANGES and return what modes are actually programmed
• Question remains: If we pretend to be Ardupilot/PX4 (and i think we have to, because compatibility is easier than getting integrated into a bunch of different projects) we have to accept that some things will be broken and stay broken

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.