Initial reorder tolerance value should not be 0

[maxsharabayko]

Reorder Tolerance

SRTO_LOSSMAXTTL sets the maximum reorder tolerance value. The internal algorithm
checks the order of incoming packets and adjusts the tolerance based on the reorder
distance, but not to a value higher than the maximum.

SRT starts from 0 tolerance. Once it receives the first reordered packet, it increases the tolerance to the distance in the sequence discontinuity of the two packets.
After 10 consecutive original (not retransmitted) packets come in order, the reorder distance
is decreased by 1 with every such a packet.

Refer to statistics.md (PR #897) for a more detailed description.

A Point of Improvement

Having 0 as the initial tolerance has a notable drawback for File CC. FileCC starts in the "slow start" mode, trying to probe the network for the highest possible sending rate.
The very first discontinuity in sequence numbers of the incoming packets will trigger a loss report. Even if the discontinuity is caused by packet reordering, the initial tolerance value is 0, and this situation will be treated as a loss.
Slow start assumes that packet losses are due to network congestion. Therefore, FileCC switches from the "Slow Start" mode to AIMD (additive increase/multiplicative decrease) operation mode, starting at the current sending rate, that will be far lower, than the actually available bandwidth.

Having initial reorder tolerance value equal to the one set via SRTO_LOSSMAXTTL will avoid such situations. This might delay some reports of actually lost packets.
The algorithm of decreasing the reorder tolerance should move the connection to the stable operation mode.

Status: Waiting for #931: Add SRTO_LOSSMAXTTL to srt_getopt(...)