Block sending DEVICE_PING messages OTA when not connected. This prevents the TX from going to telemetry boost mode (1:2) on entering Lua and confusing users with OLED display. The operative flag is the CRSF::ForwardDevicePings member.

Details

Users with the OLED display that actually shows what TLM ratio the TX is actually running at are a bit confused when they configure the TX to be at 1:128 (or any ratio, including Off) and seeing that the OLED is showing the TX is in 1:2 mode. The issue is that when the user enters the Lua, a DEVICE_PING is queued to see what other connected devices are out there. In normal operation this is fine, but when disconnected the TX will stay in 1:2 mode until a receiver connects and the PING is able to be forwarded.

However, there are circumstances when we want to go into 1:2 mode even when disconnected. This allows BF.lua and SendVTX to work even when TLM Ratio is set to Off. A receiver is out there, the user has just elected to prevent us from knowing it is out there and switching to 1:2 will create the bidirectional tunnel we need to transfer MSP packets.

Therefore, DEVICE_PING is unique in that it is not sent by user request and thus the confusion about why the radio is in 1:2. This PR modifies the TX behavior so that DEVICE_PINGs are not queued if disconnected. Wow. That's the longest PR details I've ever had before I got to what the actual PR is about.

Other Fixes

• Our MSP sender on the TX side was always sending 65 bytes OTA for every MSP passthrough packet from the handset. I've confirmed this both on the TX side (counting the number of MSP send packets at 5 bytes each) and RX side (displaying the currentOffset at the end of receiving the MSP transfer). The receiving side always ignored the extra bytes. I've modified the code to only send as much MSP data as we have, 10 bytes for DEVICE_PING, 15 for BF.lua Init, etc. You'd think this would result in a massive speed boost especially at 50Hz where max MSP bandwidth is 62.5 bytes/sec, but it is barely noticeable in practice as I switched back and forth between the two transfer lengths. In any case this increases our upstream MSP bandwidth significantly (400%-600%).

MSP before: 238 4 40 0 234 84 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MSP after:  238 4 40 0 234 84

• Since I updated the tests for this PR, I'm also trying to take a stab at fixing running the tests on Windows and GitHub thanks to our bswap code being double defined / not defined on some platforms when running tests vs building firmware. This might take a few pushes to get the right combo and defines. EDIT: successkid meme