[FR] Send out-of-band user data

[maxsharabayko]

This PR is a PoC and WiP. Addresses #2397.

Allow sending some OOB user data bi-directionally over an existing SRT connection.

1. Unreliable delivery. If a packet is lost, neither the receiver nor the sender would ever know. An application's responsibility is to track losses and retransmissions of those packets if required.
2. These packets are sent just like other control packets: bypassing the data packet sending queue, and ignoring MAXBW limit and any kind of pacing from the SRT side.
3. Incoming packets are not buffered by the receiver, and outgoing packets are not buffered by the sender.
4. It is not possible to send/receive a message not fitting into a single packet❗ Due to item no. 4.
5. Encryption: not yet implemented.
6. Group connections Currently not supported.
7. Reading an incoming user data message blocks the receiving thread❗ Thus must not take too much time. Alternatively the message has to be buffered by the SRT receiver to initiate the callback from a different thread.
8. SRT_UDCTRL::timestamp is ignored at the moment❗

SRT API

// A control structure with additional fields.
struct SRT_UDCTRL {
    uint32_t timestamp;
};

/// @param u SRT scoket with an established connection.
/// @param buf data to send (must fit in one MTU!).
/// @param len length of the data to send.
/// @param udctrl control structure with additional fields, mainly for possible future extenstions.
int srt_senduserdata(SRTSOCKET u,  const char* buf, int len, SRT_UDCTRL *udctrl);


typedef int srt_userdata_callback_fn   (void* opaq, SRTSOCKET u, const char* buf, int len, const SRT_UDCTRL* ctrl);
SRT_API       int srt_userdata_callback(SRTSOCKET u, srt_userdata_callback_fn* cb_fn, void* opaque);

• Should the sender get an additional field to provide the sequential packet ID?

SRT Protocol

Extend the User Data Control type packet:

+===================+==============+=========+===============+
| Packet Type       | Control Type | Subtype | Section       |
+===================+==============+=========+===============+
| (...)                  | (...)  | (..) |
+-------------------+--------------+---------+---------------+
| User-Defined Type |    0x7FFF    |    -    | N/A           |
+-------------------+--------------+---------+---------------+
              Table 1: SRT Control Packet Types

Control Type = 0x7FFF (User Defined Data, UDTMessageType::UMSG_EXT).
Subtype:

• 1 = HSREQ
• 2 = HSRSP
• 3 = KMREQ (encryption key material request)
• 4 = KMRSP (encryption key material response)
• 5 = User Data (Unreliable Delivery)

The user-data packet itself has the following structure.
Some means to identify sequential packet number might be needed unless handled by the application.

• The "type-specific information" field may allow an application to define the type of packet instead of putting a marker inside the "free-form text" field.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|   Control Type = 0x7FFF     |            Subtype = 5?          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Type-specific Information                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Destination Socket ID                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- CIF -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                      Free form text content                   +
                               ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+