Update MAVLINK message definitions

[chemicstry]

Current MAVLINK message definitions are 2 years old and many new messages are missing.

[chemicstry]

There seems to be some problems with the embedded build, marking as draft until I figure it out

[chemicstry]

I think it should be OK now. The display="bitfield" was deprecated in MAVLINK and now it is defined as bitmask="true" on enum instead. However, there are still cases of both so we have to support each case.

[pv42]

Last time I looked into updating MAVLink definition the issue was that there are enums that are both used as bitmasks and as single choice selections (See #285) but error message looks different this time.

[chemicstry]

Yeah, it seems that there is no consensus on the display="bitmask" and it's random across dialects. I got past it though and currently I'm stuck on different messages using different primitive type for the same enum. I.e. GIMBAL_DEVICE_CAP_FLAGS is u16 in common, but u32 in storm32.

UPDATE: since enum definition does not have a defined size, it is only taken from field definitions, so there is no single source of truth for enum size. I believe the only way is to hardcode exception for offending messages. Or maybe determine enum primitive based on maximum flag value?

[chemicstry]

I narrowed this down to 2 issues:

• STORM32_GIMBAL_MANAGER_INFORMATION has a u32 field for u16 enum. Fixing this requires some invasive parser modifications and I think is better left for another PR. I added it to a new message filter. This message was not available before the definition update, so there is no regression.
• ILLUMINATOR_MODE being used as both enum and as a bitmask is IMO a message definition issue. With the current definition of ILLUMINATOR_MODE_INTERNAL_CONTROL = 1 and ILLUMINATOR_MODE_EXTERNAL_SYNC = 2 there isn't an issue, but what if a third value is added? Is it going to be 3 (enum) or 4 (bitmask)? Currently it is interpreted as bitmask in all fields so it shouldn't cause issues with usage as opposed to it being an enum (more restrictive).

[hamishwillee]

Are you actually using the mavlink version for anything? i.e. does your code check it? AFAIK no code bothers to check this so there is no point updating it. If we start a release process, then perhaps we will.

I will look at the build issues tomorrow.

[chemicstry]

Sorry for the confusing PR name, intention is to update message definitions.

[patrickelectric]

@chemicstry can you rebase it ?