Implement adaptive reorder tolerance from libsrt

[fyzali]

• Add receiver-side adaptive reorder tolerance with REXMIT flag negotiation
• Defer NAKs via fresh-loss TTL handling and revoke on TLPKTDROP

[gemini-code-assist]

Important

Installation incomplete: to start using Gemini Code Assist, please ask the organization owner(s) to visit the Gemini Code Assist Admin Console and sign the Terms of Services.

[ioppermann]

Thanks for your contribution. I have a few remarks:

I see that you use the REXMITFLG to indicate whether to use the adaptive reorder tolerance feature and thus removed it from the checks in conn_request.go and dial.go. However, the specs say that this flag MUST always be set.

REXMITFLG flag MUST be set. It is a legacy flag that indicates the peer understands the R field of the SRT DATA Packet
https://haivision.github.io/srt-rfc/draft-sharabayko-srt.html#section-3.2.1.1.1

This means, this feature should always be on if the value of LossMaxTTL in the listen or dial config is greater than 0 ( see here: https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#SRTO_LOSSMAXTTL). This means that the Receiver.SetReorderSupport(enabled bool) is not needed and it should be automatically enabled if the MaxReorderTolerance is greater than 0.

[fyzali]

"the specs say that this flag MUST always be set." It is correct.

Basically we always advertise REXMITFLG. But we do not drop connections if peer flag is not set. It is in inline with implementaion of Haivision’s libsrt (they are keeping this behavior for interoperable with older peers).

If you recommend I can update behavior according to specs.