[core] Improved input rate calculation.

[maxsharabayko]

Fixing bandwidth limitation mode with automatic input bitrate R_input calculation. Configuration SRTO_MAXBW=0, SRTO_INPUTBW=0, live transmission mode.
In this mode the bandwidth limit is R_input * (1 + OHEAD), with R_input calculated based on the number of packets added to the sender's buffer (via srt_send*).

The desired behavior of the input rate calculation:

1. Fast start period of 0.5 sec or 2000 packets to accumulate enough statistics. Meanwhile use default MAXBW + overhead.
2. If 0.5 seconds have passed or 2000 packets have been sent, calculate input rate R_input. Update MAXBW = R_input * (1 + OHEAD). Switch to RUNNING mode with input rate update every 1 sec.
3. In RUNNING mode update R_input every second and recalculate MAXBW = R_input * (1 + OHEAD).

Note. 2000 packets roughly equals to 21 Mbps of 1316 bytes payload. Therefore the condition is true after 0.5 s of 40 Mbps streaming, and the earlier the higher the bitrate is. E.g. for 400 Mbps streaming the input rate will be calculated already after 50 ms.

Changes introduced by this PR

Issue. Initial Input Rate of 10 Mbps for Fast Start Period

The initial input rate for fast start period was only 10 Mbps
static const int SND_INPUTRATE_INITIAL_BPS = 10000000/8;
Now it equals the BW_INFINIT value (30 Mbps, or 1 Gbps after PR #760):
static const int INPUTRATE_INITIAL_BYTESPS = BW_INFINITE;

Issue: Wrong Initial Sampling Period

Wrong condition in CUDT::updateCC. Switching to RUNNING mode on 2000 packets condition does not update the input rate, instead the update is delayed for 1 second instead of 0.5 seconds.

if ((m_stats.sentTotal > SND_INPUTRATE_MAX_PACKETS)
    && (period < SND_INPUTRATE_RUNNING_US))
{
    m_pSndBuffer->setInputRateSmpPeriod(SND_INPUTRATE_RUNNING_US);
}

SND_INPUTRATE_MAX_PACKETS = 2000

Input Rate for Idle Connections (TO DISCUSS)

After this PR the input rate is updated only when new packets are added to the sender's buffer.

Previously the input rate was also updated for idle connections, meaning that if there is a temporal congestion on the link, the input rate estimation might decrease. In this case decreasing the input rate of an idle link is not the desired behavior, because it also decreases the bandwidth limitation, while the expected live stream rate should be at least the same.
Although in some cases it might make sense to decrease the bandwidth limit to decrease the rate of packet retransmission.

CUDT Control Over CSndBuffer's Rnput Rate Calculation Sampling Period

Now CSndBuffer controls input rate calculation sampling period internally, allowing the CUDT to reset the mode back to FAST START.

• CSndBuffer::setInputRateSmpPeriod(int period); made private
• Added CSndBuffer::resetInputRateSmpPeriod(bool disable)

TODO

• Change logging mode around the input rate calculation back to heavy logging
• Make auto bandwidth limit based on the calculated input bitrate the default mode in SRT. Add a recommendation note to set the input bandwidth though.

[maxsharabayko]

Streaming 500 Mbps with master banch. Default configuration,maxbw=0

As can be seen on the plots shown below, the initial bandwidth limit of 30 Mbps is active for the first 1 sec. Although after roughly 100 ms the TSBPD mechanism takes over and forces the sender to transmit faster (issue #713 TSBPD suppress max BW limitation).
After 1 sec the input rate is updated, then the bandwidth limitation is updated, and there is a temporal spike in sending rate when sending the buffered packets.

[maxsharabayko]

Streaming 500 Mbps with master banch. Default configuration, maxbw=0, tsbpd=0, tlpktdrop=0.

[maxsharabayko]

Streaming 500 Mbps with this PR banch. Default configuration, maxbw=0, tsbpd=0, tlpktdrop=0.

[maxsharabayko]

2 sec streaming 500 Mbps with this PR banch. Default configuration, maxbw=0.

[maxsharabayko]

10 sec streaming 500 Mbps with this PR banch. Default configuration, maxbw=0.