Mavlink Refactor + Multiple Serial Ports

[xznhj8129]

MAVLink multi-port refactor, routing, protocol fixes, and MSP-over-MAVLink tunnel

** Draft WIP, some things need to be adjusted, refactored or changed including user setup workflow, settings; configurator (seperate PR); as well as flight testing **
** Test tooling for routing, performance stress testing and telemetry will be included soon **

Summary

Substantial refactor of INAV's MAVLink implementation. The main goal is to turn the existing single-block MAVLink telemetry code into a modular MAVLink subsystem that can support multiple concurrent MAVLink ports, more correct routing and message handling, and a broader set of MAVLink interactions needed by modern GCS and radio workflows. This enables you to use multiple Mavlink ports for receivers, GCS links, computers, gimbals, cameras and more as you would expect from a Mavlink vehicle. The routing is based on Ardupilot.

The old src/main/telemetry/mavlink.c file was split by responsibility instead of continuing to accumulate all MAVLink behavior in one place. Runtime state, port lifecycle, and active-port context moved into src/main/mavlink/mavlink_runtime.c; stream scheduling and periodic message emission into src/main/mavlink/mavlink_streams.c; route learning and forwarding into src/main/mavlink/mavlink_routing.c; mission upload/download and frame handling into src/main/mavlink/mavlink_mission.c; mode mapping into src/main/mavlink/mavlink_modes.c; and FC-facing command handling plus MSP-over-MAVLink tunnel handling into src/main/fc/fc_mavlink.c. Shared types and internal interfaces were moved under src/main/mavlink/, leaving the telemetry entry layer much thinner and making further MAVLink work more tractable.

On top of that refactor, this branch adds MSP-over-MAVLink Tunnel Service support so the INAV Configurator can talk MSP over an existing MAVLink telemetry link, typically over a radio that does not expose a separate MSP transport. The configurator patch adds a "Mavlink Tunnel" option when Wireless Mode is selected and allows specification of SYSID for multi-vehicle networks.

See docs/Mavlink.md

What this branch changes

• Splits the old monolithic src/main/telemetry/mavlink.c implementation into focused modules for runtime, streams, routing, mission handling, modes, and FC-facing message handling.
• Adds support for up to 4 concurrent MAVLink telemetry ports (MAX_MAVLINK_PORTS), with per-port runtime state and per-port configuration.
• Adds route learning and forwarding between MAVLink ports:
  • learned routes are tracked by (sysid, compid) -> ingress port
  • targeted traffic is forwarded only where a route is known
  • broadcasts are forwarded to other MAVLink ports, with local handling rules for specific control messages
• Keeps one fixed local FC MAVLink identity as (mavlink_sysid, MAV_COMP_ID_AUTOPILOT1) instead of introducing per-port FC component IDs; attached devices remain remote routed components learned from traffic.
• Moves MAVLink configuration from a single global port model to per-port settings:
  • mavlink_port{1-4}_*_rate
  • mavlink_port{1-4}_min_txbuffer
  • mavlink_port{1-4}_radio_type
  • mavlink_port{1-4}_high_latency
• Keeps port 1 as the main fully-streaming MAVLink port by default, while ports 2..4 start in a conservative profile with heartbeat enabled and other streams disabled until requested.
• Support of High Latency service
• Adds half-duplex etiquette improvements so a shared MAVLink RX/telemetry serial link configured with serialrx_halfduplex backs off after RX before transmitting.

Protocol and behavior improvements

• Includes the mav_fix2 behavior fixes that were already part of the branch history.
• Adds proper local execution for broadcast/system-broadcast control traffic where appropriate
• Replaces the older stream-bucket-only MAV_CMD_SET_MESSAGE_INTERVAL behavior with per-message interval overrides layered on top of the existing stream model.
• Splits some periodic scheduling out of shared stream buckets so messages such as GPS_RAW_INT, GLOBAL_POSITION_INT, BATTERY_STATUS, SCALED_PRESSURE, and SYSTEM_TIME can be controlled more correctly.
• Adds SYSTEM_TIME output and corresponding request/interval support.

MSP-over-MAVLink tunnel

• Requires configurator change
• Adds MSP transport over MAVLink TUNNEL using private payload type 0x8001.
• Reuses the existing MSP parser and encoder outside the normal serial-only path by exposing the needed parser/command/encode entry points from msp_serial.
• Preserves MSP framing symmetry end-to-end:
  • MSPv1 requests receive MSPv1 replies
  • MSPv2 requests receive MSPv2 replies
• Replies are emitted back on the ingress MAVLink port only.
• Supports reboot post-processing over the tunnel.
• Explicitly rejects serial passthrough and ESC 4way passthrough over the tunnel.
• Requires MAVLink 2 for tunnel transport.

User-visible impact

• INAV can now host multiple MAVLink telemetry ports at the same time instead of behaving like a single-port MAVLink endpoint.
• Ground stations and companion links can request streams and particular messages.
• Routing is now usable for multi-endpoint and relay/radio setups.
• Broadcast-targeted MAVLink control traffic behaves more like operators and GCS software expect on multi-endpoint networks.
• Guided commands, stream interval requests, capability requests, and mission interactions behave more consistently with MAVLink expectations than before.
• Configurator access over an existing MAVLink telemetry link becomes possible through MSP-over-MAVLink tunnel support.

Documentation and tests

• Adds a dedicated docs/Mavlink.md document describing the implemented behavior, supported messages/commands, routing, stream configuration, tunnel support, and known MAVLink differences.
• Updates MAVLink-related settings documentation and MSP development docs where relevant.
• Adds a large unit test suite in src/test/unit/mavlink_unittest.cc covering routing, mission flow, guided commands, stream intervals, protocol/capability requests, telemetry details, and MSP tunnel behavior.
• The branch also includes live SITL validation of the refactored implementation, including a routing compliance pass and an end-to-end MSP-over-MAVLink tunnel smoke test with reboot and reconnect recovery.

Important limits / non-goals

• This does not turn INAV into a full ArduPilot/PX4-class MAVLink vehicle implementation.
• MAVLink parameter API support remains intentionally minimal.
• Ports 2..4 do not start with full stream output by default.
• Directed forwarding depends on route learning, so the first targeted packet to a never-seen endpoint may not forward until that endpoint has transmitted at least once.
• MSP-over-MAVLink is for configurator/MSP access over MAVLink links; it is not intended as a generic serial tunnel, and CLI mode is not provided over this path.
• MAVLink mission support remains intentionally partial and does not provide full parity with INAV's MSP mission model.

Open Questions

• Why only 4 ports? Sounded reasonable
• Performance and Flash size cost? TBD
• Registration of MSP as a formal Mavlink tunnel service payload type
• TBD