Added new option: SRTO_SNDDROPDELAY

[ethouris]

This option influences the condition under which the SND-DROPPING happens (dropping packets already at the sender side when it would be useless as the receiver will drop them anyway due to coming too late).

This option defines an extra delay time that can be applied to check, if sending wouldn't be too late, or may even disable SND-DROPPING completely if set to -1. The unit is, like latency, in ms. An important treat of this option is that, in contrast to SRTO_LATENCY and SRTO_TLPKTDROP, this option may be altered also when the socket is connected, that is, the application may manipulate this option during transmission.

[jeandube]

This PR only permits to extend the delay. To enable full control I would replace it by SRTO_SNDDROPMINDELAY and set the value currently hard coded. This way it can be set to 0 and the delay will depends on the configured SRTO_LATENCY. I would also restore the possibility to disable TLPKTDROP in a sender (preferably with a setting independent for RCV and SND. And finally I would study the possibility to enable send flow control (EWOUDBLOCK) based on the SNDDROP value instead of the full send buffer size. I assume that setting the send buffer size after handshake (and Latency agreement) is more complex than setting a threshold.

[ethouris]

Currently this delay threshold is defined as:

    int threshold_ms = std::max(m_iPeerTsbPdDelay_ms, SRT_TLPKTDROP_MINTHRESHOLD_MS)
            + (2*COMM_SYN_INTERVAL_US/1000);

Where SRT_TLPKTDROP_MINTHRESHOLD_MS is 1000, and this is the actual minimum to wait, the next part results in 20ms.

This option is predicted to allow to track the problem when the sender-tlpktdrop is overreacting, that is, it drops the packet that wouldn't be dropped by TLPKTDROP on the receiver. If we want to have a value that would be less than the currently defined threshold, it should allow us to overreact even more. Not sure what we'd like to achieve with such testing, but maybe it has some merit, although I'd prefer rather a value of 0 to maintain the current state, with possibly a negative value that would be used to subtract from the current extra delay (1020). Just a little bit doubtful would be then using the -1 value as a special value to turn off sender TLPKTDROP.

This way you'd have to set snddropdelay=-1020 in order to have a delay only so big as the latency.