Update TSBPD base time and clock drift on an idle connection.

[maxsharabayko]

Normally the TSBPD base time is updated on the receiver side based on timestamps of incoming SRT data packets.
Clock drift estimate is updated based on ACK-ACKACK packet pairs, on the receiver side.

Note

TSBPD base time update with this PR happens only if the new receiver buffer is used.

1. Idle Connection

In case of an idle connection only KEEPALIVE packets are being sent to the peer. They must be used to track the TSBPD base time carryover. The carryover happens every 01:11:35 (HH:MM::SS) hours once the timestamp field of an SRT packet no longer has enough bits to represent a packet timestamp based on the current TSBPD time base.

A keepalive packet is sent every 1 second if a connection is idle. The TSBPD wrapping period starts 30 seconds before reaching the maximum timestamp value of a packet and ends once the packet with timestamp within (30, 60) seconds interval is delivered (read from the buffer). Therefore the keepalive period should be enough to properly handle the carryover of the timestamp.

Clock drift also has to be updated. In case of KEEPALIVE packets there is not RTT estimate available, thus deviations in network delay may affect the tracing.
Also currently drift tracer accumulated 1k samples to perform an update. In case of keepalive packets a new sample is added every 1 second, and drift update would take quite a long time.

2. SRT Sender

Addressed in PR #2435.

TODO

• The drift value is updated every 1k samples. In case of tracking drift with KEEPALIVE packets it would be happening quite infrequently. This requires changing the drift tracing model.
• Do not use Lite ACK to track drift, because it would be too often. Only use full ACK.
• If an idle socket is a member of a group, just use the TSBPD and drift updates from an active member (if there is one).

Addresses #1936

[maxsharabayko]

Experiment

• Establish SRT connection. SRT latency: 1 second.
• Wait for 2 hours (nothing sent, but stays connected).
• Then start 1Mbps streaming for 30 seconds.

This PR

With the fix on updating TSBPD base using KEEPALIVE packets, the receiver starts streaming at the expected end-to-end latency of 1 second. The expected transmission delay (system clock delta) is above 3 seconds in this case.

Drift correction of ~20ms happens after 15 seconds of streaming. The correction is not that big, meaning that drift adjustments were also handled properly on keepalive packets, although not as accurate as they could have been if RTT could be estimated.

SRT v1.5.0

Without the fix after around 1 hour 11 minutes the TSBPD base time resets back to zero, and the receiver is not aware of it.
Because of that when sending starts, the calculated delivery time of each packet is located way in the past. All the packets arriving are delivered to the receiving app immediately.
The transmission delay is 2.2 seconds (note the system clock difference). Thus there is no buffering of a packet. Some packets are dropped by the receiver without attempting to retransmit them.

SRT v1.5.0 CBR

To compare to the expected transmission delay (system clock delta) here are the results of 1Mbps streaming for the whole duration of the experiment (2 hours).