Add UDP support to our Telemetry Stream

[stieg]

Telemetry streams over TCP are often subject to delays caused by poor network conditions. While normally this delay is small and hard to notice (brief stutters in the stream) it can become substantial, especially as network congestion grows or as cellular network reliability drops.

I propose that we add UDP support to our telemetry stream so we may degrade gracefully when we hit poor conditions or congestion. In doing so we drop traffic that fails to send instead of trying to resend it. By doing this we:

• Minimize the time it takes for a sample to reach our servers
• Maintain a stead stream of data, which is easier to optimize and handle
• Gain the ability to work with limited bandwidth by dropping what the network can't send

Of course the counter to this is that we may lose data in situations where TCP would have preserved it. To me this is a fair trade-off so long as we have a good back-fill story. For now that story would be uploading the contents of the SD-Card after the day is done to get a complete view of the session. To do this we would need to ensure the following:

• Have some form of Telemetry Session ID in place to be able to label the session ID
• Design behavior around scenarios where the server doesn't know the meaning of all data channels (should a header packet get lost).

We should also eventually add the following when time permits:

• Have some form of basic packet auth in place so users can't easily forge samples
• Have some form of TCP channel in place to be able to reliably send and receive commands to the unit.

[stieg]

Telemetry Streams ID issue is tracked by #791