Deprecate all non MISSION_*_INT usage

[hamishwillee]

Fixes #1285

To progress this, have created PR. Docs will have to be updated too. Original description below

---

As it currently stands there is a hole in the mavlink spec with respect to _INT usage. There is a capability bit on the vehicle side. But there is no clear way to know whether the GCS side will support uploads of MISSION_ITEM_INT items. The only sideways sort of way to do that would be for the vehicle to remember if the GCS did a MISSION_REQUEST_INT. To both deal with that and remove complexity from the mavlink spec I propose a breaking change to only allow support for the _INT variants of the protocol.

• This would mark MISSION_ITEM, MISSION_REQUEST and MAV_PROTOCOL_CAPABILITY_MISSION_INT as deprecated.
• A gcs is required to support the _INT based protocol sequence.
• If a gcs receives old non _INT requests it always respond with _INT responses.This provides an interim transition path to the future while these messages still exist. I've tested this in QGC and it works fine against PX4 and ArduPilot.

This reflects the reality of PX4/ArduPilot/QGC/MP of today which supports the _INT based protocol. I don't see any reason to maintain the non _INT protocol moving forward. So gets reduce complexity and get rid of it.

Related to #8122

[hamishwillee]

FYI @DonLakeFlyer @auturgy

It seems to me that this simplifies things, and breaks nothing. Any opposition to merging? I will then have to update docs as a follow up.

[auturgy]

@peterbarker can we test against MAVProxy?

[peterbarker]

@auturgy this only deprecates the messages, so unless someone acts on the deprecation warning it won't have any effect.

MAVProxy does have a setting which forces it to use _INT, so it won't break totally even if the messages were removed.

[hamishwillee]

@auturgy @DonLakeFlyer @julianoes That sounds like "OK to proceed"?

[julianoes]

Generally, I think that makes sense.

MAV_PROTOCOL_CAPABILITY_MISSION_INT as deprecated.

I'm not sure about this one. If it is deprecated, does that mean the autopilot should not set it anymore? If so, this would potentially break things because e.g. MAVSDK expects this to be set. If it is not set MAVSDK will refuse to upload/download missions as it (already) doesn't support non-int transfers.

Therefore, I would maybe describe it as "always has to be set" if missions are supported.

[DonLakeFlyer]

How often is stable updates of MAVSDK? If not too long just fix it and push into next stable. It will take time for new firmwares to stop sending the bit anyway. By the time that happen there could be a new mavsdk can't there.

[DonLakeFlyer]

No that won't really work. So do this in stages. Mark the cap bit as continue to be sent, but ignored by updated consumers. With a deprecation date where it disappears. Then at that time all consumers will need to be up to date with latest spec.

[hamishwillee]

@julianoes I tidied up the description of MAV_PROTOCOL_CAPABILITY_MISSION_INT to reflect better what @DonLakeFlyer is saying.

I share your concern. We use this flag to say "we have been updated and we expect this type of item". If feels wrong to say "we trust that you'll always send us the right type irrespective of what we put in here". This is where I want the microservices versioning protocol in place to remove the ambiguity.

Don, I don't understand the harm on this being set, though I do understand that when all systems are updated this would no longer be necessary.

Julian, are you convinced by Don's suggestions?

[julianoes]

Mark the cap bit as continue to be sent, but ignored by updated consumers. With a deprecation date where it disappears.

Yes, that makes sense.

@hamishwillee I think you have it the wrong way round.

No longer required. Systems that support missions should ignore this flag and always return a MISSION_ITEM_INT rather than a MISSION_ITEM (deprecated).

The flag is set by the autopilot (and not the ground station) as I understand it.
Therefore, the flag is still required because it means that MISSION_INT can be chosen. By not setting the flag, older implementations of MAVSDK will break because they expect it to be set.

I would formulate like this:

This flag always needs to be set because MISSION_ITEM_INT is to be used rather than MISSION_ITEM which is deprecated.

[julianoes]

How often is stable updates of MAVSDK?

Irregular but generally every few weeks. However, if possible I try to keep things compatible as much as possible.

[hamishwillee]

@hamishwillee I think you have it the wrong way round.

I know what I mean, but my wording could still be bad. 2. This is supposed to be capturing the text "If a gcs receives old non _INT requests it always respond with _INT responses."

I'll make it the way you suggest.

[hamishwillee]

@DonLakeFlyer @julianoes You OK to merge this PR? Note Don that for now this should still be set (which I believe was the result of the discussion).

[julianoes]

Ok!

[hamishwillee]

OK, I am merging this. We want to make it very clear that MISSION_ITEM should no longer be used and this does that. The arguments around the capability bit can be addressed later.