autotest: improve diagnostics around log download

[peterbarker]

I did consider factoring this, but thought laying out the mavproxy commands in one place was better, still. I reserve the option to change my mind there....

[peterbarker]

• MAVProxy's retry logic needs help
  • 20 retries/0.7 seconds isn't appropriate, should be a bandwidth limit for requests-sent
  • current logic will retry the same blocks all the time (until they're satisfied
    • should be creating a queue of requests when the queue is empty, then empty the queue
    • until full size is reached that queue would just have the chunk missing from the end
• ArduPilot should ignore attempts to change the span being downloaded while it is sending a span
  • this will allow MAVProxy to continue to request the final bit of the file without causing the autopilot to resend chunks which are still in transit
  • • AP_Logger: send data requested before handling new xfr req on same file #26412
• the current autotests involving MAVProxy are fundamentally flawed when using an unreliable transport such as UDPMulticast.
  • MAVProxy has no retry for "log list". If replies are lost (and they are!), then MAVProxy never emits the key string which the autotest suit is looking for ("logNum" etc)
• there appears to be a bug in mavproxy_log.py
  • if a log is an exact multiple of 90 bytes long then we will not fill gaps
  • line 65, m.count==0
• we still have problems with draining mavs when expecting