[core] make sure data to be inserted into CRcvLossList are monotonic

[gou4shi1]

fix #2192 (comment)
Previously, these is a comment saying that Data to be inserted must be larger than all those in the list, guaranteed by the UDT receive, let's guarantee this by the internal check.

[gou4shi1]

The result of this PR:

20:15:15.522705/SRT:RcvQ:w1 D:SRT.qr: @812622476: processData: m_pRcvLossList->insert(1571759771 1571759771)
20:15:15.522719/SRT:TsbPd D:SRT.qr: @812622476: dropFromLossLists(): m_pRcvLossList->remove(1571759766, 1571759771)
20:15:15.522753/SRT:RcvQ:w1*E:SRT.qr: RCV-LOSS/insert: IPE: (1571759771,1571759771) to be inserted too small: m_iLargestSeq=1571759771, m_iLength=0, m_iHead=-1, m_iTail=3 -- REJECTING

This log was printed frequently, maybe we should turn down it's level.

[maxsharabayko]

@gou4shi1 thank you for this elegant solution!

If the warning message is printed too often, then in addition to this fix, it probably makes sense to find a way to properly synchronize changes to the buffer and loss list. Decreasing log message severity instead will just hide the problem. Will take some time to think. 🤔

Reviewer TODO

• Check this PR conflict neither with packet filter, nor with the packet reorder tolerance logic.

[gou4shi1]

If the warning message is printed too often, then in addition to this fix, it probably makes sense to find a way to properly synchronize changes to the buffer and loss list.

If those debug logs are disabled, this warning message will not be printed frequently, otherwise, #2192 would be very easy to reproduce :)
During debugging, I think CRcvLossList deserves more sanity checks, I will submit more PRs to add checks with __builtin_expect() and unit tests.

nor with the packet reorder tolerance logic.

I have checked the logic of packet reorder tolerance, seq that was dropped by tsbpd may still be inserted into m_FreshLoss, which may result in some useless lossreports, but it should be fine since ack will be updated correctly.