GCS_MAVLink: Support requesting MESSAGE_INTERVAL via REQUEST_MESSAGE cmd

[nexton-winjeel]

Updates the MAV_CMD_REQUEST_MESSAGE handler with a special case for requesting the MESSAGE_INTERVAL message. The old method of using MAV_CMD_GET_MESSAGE_INTERVAL is deprecated.

Raised in this Discord message: https://discord.com/channels/674039678562861068/728017546313466047/1293342302261219329

[nexton-winjeel]

FYI: @peterbarker

[peterbarker]

Please create an autotest for this.

This won't be the final shape of this functionality - it should be inverted, with handle_command_get_message_interval implemented in terms of handle_command_request_message and eventually going away.

The method you're modifying will need to be a lot more involved to support the "instance" parameter generally - but it will be nice to be able to request a specific battery instance, for example.

... and per-instance message rates are going to be "interesting".

I'm happy with this implementation, it just needs a regression test - which is going to be maybe 3 lines in rover.py or something.

[nexton-winjeel]

Please create an autotest for this.

Added an autotest to Rover.

[peterbarker]

Test is good.

Just needs to pass Python cleanliness. You can run flake8 on the command-line against the file. I run it as part of my git commit hooks to avoid pushing stuff which doesn't work. And recently using fly-check.

[nexton-winjeel]

@peterbarker: Can I get you to review this again?

[peterbarker]

Suggested change

	const mavlink_command_int_t msg_interval_cmd = { packet.param2, };
	const mavlink_command_int_t msg_interval_cmd { command : packet.param2, };

Sorry, but I don't think we should rely on the magic packing stuff that mavlink does in its messages to do this!

[nexton-winjeel]

Updated.