[core] Fixed the inconsistency between getFirstLostSeq() and ackDataUpTo()

[gou4shi1]

I found the ackDataUpTo: IPE logs from #2463 happened frequently, e.g.

11:05:45.433712/SRT:TsbPd!W:SRT.br: @965985327:RCV-DROPPED 53 packet(s). Packet seqno %1675849901 delayed for 234.185 ms
11:05:45.433777/SRT:RcvQ:w1*E:SRT.xt: @965985327: ackDataUpTo: IPE: invalid ACK from %1675849901 to %1675849848 (-53 packets)

It may caused by the inconsistency between getFirstLostSeq() and ackDataUpTo():

[RcvQ] m_pRcvLossList->getFirstLostSeq() -> 1675849848
[TsbPd] rcvDropTooLateUpTo() -> 1675849901
[RcvQ] ackDataUpTo() -> 1675849848 < 1675849901!

So getFirstLostSeq() should be protected by m_RcvBufferLock together with ackDataUpTo().

[codecov-commenter]

Codecov Report

Merging #2488 (d18df82) into master (04369b8) will decrease coverage by 0.14%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2488      +/-   ##
==========================================
- Coverage   66.10%   65.96%   -0.15%     
==========================================
  Files          96       96              
  Lines       19599    19602       +3     
==========================================
- Hits        12956    12930      -26     
- Misses       6643     6672      +29     

Impacted Files	Coverage Δ
srtcore/core.cpp	59.72% <100.00%> (-0.43%)	⬇️
srtcore/cache.h	80.00% <0.00%> (-3.08%)	⬇️
srtcore/congctl.cpp	81.34% <0.00%> (-1.56%)	⬇️
srtcore/list.cpp	82.11% <0.00%> (-0.82%)	⬇️
srtcore/queue.cpp	80.59% <0.00%> (-0.60%)	⬇️
srtcore/buffer_snd.cpp	66.85% <0.00%> (+0.57%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more