Makes Reno CC slightly loss tolerant

[janaiyengar]

The key idea here is that it is unlikely that a singular loss is a good indicator of congestion. I considered using a percentage of the congestion window as the threshold, but that might be too aggressive. This PR sets the threshold to two, meaning that there have to be at least two losses in a recovery episode for there to be congestion action.

Additionally, the congestion window is increased during the recovery episode as long as the number of losses is below the threshold.

Note that the recovery episode still starts and ends as before: starting at the first loss and ending an RTT later. This means that it is possible for the window to keep increasing until threshold number of losses occur, which could be near the end of the recovery RTT. In the worst case, this causes the window to be slightly larger (Beta x MaxPacketSize) at the end of a congestion event.

[kazuho]

Thank you for the PR. The logic looks fine though I wonder if we can hard-code this.

How about adding a new factory object alongside quicly_cc_reno_init that uses the loss-tolerant variant, calling it reno-lt or something? Then, we can test the efficacy of the proposed approach.