Implement packet streaming for oversize messages

[rflandau]

With tiny headers and mostly-constrained bodies, Orv messages easily fit into a smaller-than-standard MTU of 1KB; this could likely be pushed down to 802.15.4 levels (127B) with some tuning. However, messages with strings (particularly those with service lists (string arrays)) are unbounded and thus can rapidly surpass 1KB. Thus, Orv needs a mechanism for splitting data from a single logical message into many packets.

To remedy this, Slims' protocol package should be upgraded to support messages taking the form of a stream of packets. While I do not know the exact spec, here is the current theory:

---

Streams are a collection of 'body' packets buttressed by START and END packets and every packet must be idempotent (Orv expects lossy networks!). Streams should be understandable even if incomplete and must be crafted in a way that incomplete information is acceptable (it must comply with Slims' idempotent design).

Receivers will need a configurable timeout at which point future body and END packets are considered invalid (to ensure the listener doesn't block forever on lost packets) and the stream is considered complete (even if it is missing information) so it can be processed.

• START indicates the beginning of a stream and the number of packets to follow. If START is lost, the stream may or may not be salvageable. The current idea is to act as if no packets arrived if START is lost, but this is negotiable.
• If a body packet is lost, no biggie; that piece of information will not be processed. As with all of Orv, the information can be re-requested if necessary.
• END indicates the end of a stream (s.t. the receiver can consider the message complete prior to timeout). As START packets contain the number of body packets and the receiver will have a timeout, ENDs are superfluous and exist only to enable early-exit if packets are lost.

This design necessitates a minimum MTU on Orv Slims in the way real, IPv4 fragmentation does not. Real fragmentation, of course, is a pain in the ass and can get really expensive.

Example:

LIST     | LIST    | LIST    | ... | LIST 
START    | SVC     | SVC     | ... | END
{4 pkts} | {X1@Y1} | {X2@Y2} | ... | {4 pkts}

---

This will likely require the definition of new message types, but try to consolidate and reuse messages.

The API for packet streaming still needs to be developed, but emphasis should be placed on developer control: users must be able to dictate single-packet, packet steaming, and/or hybrid service without implying support for others. Perhaps a given context cannot support packet streaming. Convenience functions (such that single packets are automatically switched to streaming) can be bolted on secondarily.