Allow changing switch mode when connected

[CapnBry]

This implements a "confirming" method of changing switch mode while connected. In addition to the existing option of the RX accepting a change in switch mode if disconnected, this code allows the switch mode to be changed if two SYNC packets with the same updated switch mode arrives back to back. In the intermediate period, channels packets are not processed to prevent them from being misinterpreted.

Why

This is an extension to #1775, which prevents sending a conflicting switch mode, but aims to resolve the issue of persistent switchmode disagreement on the RX side.

The current code does not allow a switch mode change if connected, but the way it does this is just not change switch modes. The requirement "Do not change switch modes while connected" came from the fear that maybe the SYNC packet would be corrupted in the SwitchMode field, and still pass CRC. The implementation however will still will happily misinterpret the RCDATA packets, and keep ignoring the updated switch mode.

This is a giant problem, as this has now caused what the "no change while connected" tries to prevent. The difference is that the TX actually has switched, so the RX needs to switch to continue.

Solution

This code allows a switch mode change while connected using the following algorithm on the RX

1. If disconnected, change the switch mode immediately
2. If connected / tentative, block processing of RCDATA, but store the requested switch mode
3. On the next sync packet, if the requested switch mode matches the previously requested switch mode, make the switch and resume processing RCDATA packets with the new switch mode
4. If the 2nd requested switch mode does not match the 1st requested switch mode
   a. If the 2nd mode matches the currently set mode, cancel the change and resume processing RCDATA
   b. If the 2nd mode proposes a third switch mode, return to step 2

Short version: Require two consecutive sync packets with the same switch mode if the receiver is connected.

Caveats

The receiver will essentially failsafe if the switch mode attempts to change in flight. The duration of the failsafe will be one sync interval, which is currently at most 5s for all modes. However, during this time, the RX is staying in sync with the TX, so resuming the connection will happen smoothly once the two are in agreement on the switchmode in the RCDATA packet.

This PR does not fully resolve the issue. There is still a chance that the TX will change switch modes and the RX will not get the memo due to missing the SYNC packet. This only provides a method to safely change if the SYNC disagrees with the current switch mode on the RX.

Testing notes

The easiest way to test this is without #1775 applied, but using the same procedure listed there.

• Current behavior: without this PR, the receiver will go misinterpret 8ch mode as 16ch mode and make the servos go nuts
• With this PR: When the handset reboots, the receiver will change switch modes even though it is tentative due to the incorrect switch mode on the first packet.

[CapnBry]

Labeled as 3.0 for a bugfix since it can be catastrophic if the receiver keeps doing what it currently is doing, but this is mitigated by the rarity of this occurring-- it can only really happen on Handset startup or if the user's module comes loose and resets to ModelID = 0 in flight.