[core] FileCC improvements

[maxsharabayko]

Improving FileCC. Mainly bearing with losses below 2%. Also reduced reaction on losses.

Changes to FileCC::updateSndPeriod

Experiments have shown that the bandwidth estimation value BW = m_parent->bandwidth() is not reliable enough. However, it was used to determine the highest possible sending bitrate in FileCC.

The value B determines the difference between the estimated bandwidth BW, and current sending rate R=1000000/m_dPktSndPeriod (packets per second):

B = BW - R (pkts/s)

The new sending rate will be increased exponentially the higher the value of B is.

In case BW is overestimated, the increase wll be too rapid and will instantly fall into network congestion.

Therefore, in this PR the last point where the loss was detected is used. The value of that is multiplied by two so that the increased value hits the area around that point.

loss_bw = 2 * (1000000 / m_dLastDecPeriod); // 2 times last loss point

Changes to Loss Processing FileCC::slowdownSndPeriod

When a loss report is received, FileCC enters the loss avoidance mode (m_bLoss = true).

If the number of lost packets is less than 2% of the packets in flight (unacknowledged), then do not decrease the sending rate, but do not increase as well. Remember the loss point (m_dLastDecPeriod).

Then, if the number of lost packets is higher than 2% of the packets in flight, then decrease the sending rate, but not as rapid, as it was decreased in the previous version of FileCC.

Further improvements

1. The higher the loss ratio is, the higher the sending rate is decreased. This improvement was tested in experimental branch, but is not included in the current PR.

if (CSeqNo::seqcmp(lossbegin, m_iLastDecSeq) > 0)
{
    const double mult = lost_pcent_x10 < 30 ? 1.03 : ((1000 + lost_pcent_x10) / 1000.0);
    m_dPktSndPeriod = ceil(m_dPktSndPeriod * mult);

2. speedupToWindowSize is called in case of LATE_REXMIT. This means that the sender considers some packets lost, because it does not receive neither ACK, nor LOSS report for some time. In that case FileCC should also stop increasing sending rate. At the moment FileCC ignores that.

Related PRs

#802 is to reduce the number of retransmitted packets.

[maxsharabayko]

AZ EUW to USW transmission test.
Configuration: transtype=file, messageapi=1, rcvbuf=625000000, sndbuf=625000000, fc=40000.

Congested network conditions: effective transmission rate ~550 Mbps.

The same number of packets is being transmitted. v1.3.3 takes 125 seconds to transmit the data, while the new version takes ~100 seconds.
Number of retransmitted packets (v1.3.3 vs PR): 461 242 vs 241 718

v1.3.3

This PR

[maxsharabayko]

AZ EUW to USW transmission test.
Configuration: transtype=file, messageapi=1, rcvbuf=625000000, sndbuf=625000000, fc=40000.

Better network conditions: possible transmission rate ~1500 Mbps.

v1.3.3

This PR

[maxsharabayko]

Also related to #413