AP_Frsky_Telem: replaced the passthrough scheduler with a WFQ one with rate limiting

[yaapu]

This replaces the default scheduler with a WFQ one with a rate limiter for selected packets, thus preventing link saturation.

It will be the base for adding more on top of the scheduler, like bidirectional telemetry for instance and AP_Scripting support.

It improves the library compatibility with external frsky sensors and fixes issue #12450 where adding GAS Suite and FLVSS on the s.port bus would eventually lead to starvation for lower priority packets like GPS ones.

more info on the dedicated discuss thread

@floaledm please can you check this against flightdeck, I'd like to maintain full backward compatibility!

[floaledm]

Thanks for your work on this and for asking me to review. A brief bench test seems to show it works fine with FlightDeck.

I did not read the code changes really but I read the discuss thread and share the concern about having message chunks transmitted twice, or even just once in some circumstances. I understand you're trying to juggle a lot on a very small bandwidth... not sure that having garbled messages as a result is a good tradeoff for a slightly faster update rate on other things. But overall I like the improvements so I'm not going to bicker over that. Especially since two-way will fix any problem of lost message chunks...

Great job!

[yaapu]

@floaledm thanks for testing my patches!

I read the discuss thread and share the concern about having message chunks transmitted twice, or even just once in some circumstances. I understand you're trying to juggle a lot on a very small bandwidth... not sure that having garbled messages as a result is a good tradeoff for a slightly faster update rate on other things

I'm aware that's a tradeoff but at 1 message every 4 seconds (worst case scenario with gas suite, 2 more sensors and sending messages 3 times) messages would be discarded by the force_push call because the queue would not be emptied fast enough, maybe in this case is better to send them and risk corruption vs losing them, this at least was the rationale behind my proposal.
Anyway we might add a parameter in the future and let the user decide.

[rmackay9]

this has been added to Copter-4.0.0-rc3