GCS_MAVLINK: Fix Deprecation of MISSION_REQUEST

[menschel]

Minor Protocol Issue; Finding during another investigation mavlink/qgroundcontrol#12184

MISSION_REQUEST is deprecated since 2020, replaced with MISSION_REQUEST_INT, but ardupilot still uses it to request mission items from GCS.

https://mavlink.io/en/services/mission.html#uploading_mission

[menschel]

After applying the patch.

[peterbarker]

We continue to request MISSION_ITEM so as not to break older ground control stations.

I deal with one which this PR would adversely affect (I'm nudging the author to update....).

Which GCSs have you tested with these changes?

[menschel]

I deal with one which this PR would adversely affect (I'm nudging the author to update....).

Please add a link there that marks this PR as duplicate, so it is to be closed along with it.

Which GCSs have you tested with these changes?

I'm hunting some Mavlink issues with QGroundControl and ELRS 900M, very frustrating topic because ELRS 2G4 works perfectly and mLRS 900M also works perfectly.

EDIT:
These also work with the change.

• APM-Planner_2-2.0.30-rc3
• MissionPlanner1.3.82

[menschel]

Tested again after a git hard reset onto the change, and the internal error is gone. It was likely the check in line 371 being reverted on stashed changes.

[peterbarker]

Requires ArduPilot/MAVProxy#1492

[peterbarker]

I deal with one which this PR would adversely affect (I'm nudging the author to update....).

Please add a link there that marks this PR as duplicate, so it is to be closed along with it.

That particular GCS is not open-source.

Which GCSs have you tested with these changes?

I'm hunting some Mavlink issues with QGroundControl and ELRS 900M, very frustrating topic because ELRS 2G4 works perfectly and mLRS 900M also works perfectly.

EDIT: These also work with the change.

* [APM-Planner_2-2.0.30-rc3](https://github.com/ArduPilot/apm_planner/releases/tag/2.0.30-rc3)

* [MissionPlanner1.3.82](https://github.com/ArduPilot/MissionPlanner/releases/tag/MissionPlanner1.3.82)

Nice! I've fixed MAVProxy to work with it.

We'll need to follow a process here so as to give people plenty of warning that things are going to break. It is well past time that we did follow some process to get this done.

There are many GCSs and tools out there that would be adversely affected by this patch if we were to simply merge it. MAVProxy users are likely to update relatively frequently - but uGCS users perhaps not.

We may need to carry an options bit for a while to allow a user to get the old behaviour back.

I am curious to know what real-world problem you are trying to solve with this patch. I assume there's a client which only handles MISSION_REQUEST_INT, and can't be modified to also handle MISSION_REQUESTs from the autopilot?

[menschel]

We'll need to follow a process here so as to give people plenty of warning that things are going to break. It is well past time that we did follow some process to get this done.

It would be the professional way to introduce breaking changes with a new major version.
A deprecation warning in the release notes from 4.6 onward is a fair warning of an error that will hit with 5.0 .

I am curious to know what real-world problem you are trying to solve with this patch. I assume there's a client which only handles MISSION_REQUEST_INT, and can't be modified to also handle MISSION_REQUESTs from the autopilot?

None, just a side finding. A decade or two on the job, does teach to address technical debt immediately.