GCS_MAVLink: Check if set_message_interval is too fast

[stephendade]

From #28101.

Ardupilot caps the maximum message rate at 80% of SCHED_LOOP_RATE.

If a user requests a rate faster than this via MAV_CMD_SET_MESSAGE_INTERVAL, the command now fails and advises the user to increase SCHED_LOOP_RATE.

This will prevent user confusion as per the linked issue.

Tested in SITL.

[stephendade]

Appears to be some issue with COMMAND_INT in the rover autotests. COMMAND_LONG works fine though.

Works OK with MAVProxy:

long SET_MESSAGE_INTERVAL 105 10000
command_int GLOBAL SET_MESSAGE_INTERVAL 0 0 105 10000 0 0 0 0 0

are equivalent.

Maybe some issue with the test ... will investigate further.

[stephendade]

Appears to be an unrelated test failure in DeadreckoningNoAirSpeed in Plane. but otherwise the tests are now happy.

[stephendade]

For the autotests, there appears to be an issue with context_set_message_rate_hz where it incorrectly sets the message interval:

AT-0002.6: Sending COMMAND_LONG to (1,1) (MAV_CMD_SET_MESSAGE_INTERVAL=511) (p1=74.000000 p2=10.100010 p3=0.000000 p4=0.000000 p5=0.000000 p6=0.000000  p7=0.000000)
AT-0002.6: ACK received: COMMAND_ACK {command : 511, result : 2, progress : 0, result_param2 : 0, target_system : 250, target_component : 250} (0.000000s)

So it tries to set an interval of 10.100010us (which is way above the SCHED_LOOP_RATE). Best guess there's a missing Hz->usec conversion somewhere ... can't seem to find it though :(

EDIT: This is why some of the copter and rover tests are failing. It's wherever context_set_message_rate_hz is used

[stephendade]

@peterbarker, I've fixed up the autotest issues. Appears to be 2x unrelated tests failing

[peterbarker]

LGTM

[stephendade]

For the Dev Call, since I likely won't be able to attend:
This was in response to #28101, where a user tried to get a message at a faster rate than 80% of SCHED_LOOP_RATE. This is more apparent in Rover, where SCHED_LOOP_RATE defaults to 50Hz.

[peterbarker]

Merged, thanks!