Implement spurious loss recovery

[stormshield-fabs]

Benchmarks in the cloud between two Linux machines on a 10ms/1Gbps link revealed that quinn performs consistently worse than msquic. Plotting the congestion window for both implementations shows that msquic reaches higher congestion window sizes, in part because it implements spurious loss recovery (as described in rfc8312bis which is now rfc9438).

This PR implements a similar spurious loss recovery mechanism (quinn implements rfc8312)

Lost packets are stored in the PacketSpace and used on ACK reception to determine if all the packets we deemed lost were in fact acknowledged. This list is regularly purged from packets that were sent more than 2 PTO ago (this is the value used in msquic: https://github.com/microsoft/msquic/blob/2623c07df62b4bd171f469fb29c2714b6735b676/src/core/loss_detection.c#L925).

Overall, this appears to effectively improve throughput on the benchmark I described above: we've seen up to a 30% increase in upload bandwidth.

	main	patch	gain
average	314 Mbps	391 Mbps	25%
P50	302 Mbps	402 Mbps	33%

[stormshield-fabs]

The msquic congestion window plot that helped find this difference between both implementations

Before/after plots for quinn (the orange curve is the average of all samples)

[Ralith]

Thanks, this is great work! It's much simpler than I feared, and the improved throughput is really compelling. I wonder if this will also account for our slightly lagging throughput numbers in the interop test...

I'd like to see test coverage for the new behavior.

[Ralith]

Note this is a breaking change due to the tweak to the congestion controller interface. We could adjust the design to be non-breaking, but I think it's fine; the current form is fairly natural and it's been a while.

[djc]

Note this is a breaking change due to the tweak to the congestion controller interface. We could adjust the design to be non-breaking, but I think it's fine; the current form is fairly natural and it's been a while.

Should we get another release out with non-breaking improvements before we merge this?

[Ralith]

No objection from me.

[stormshield-fabs]

We are working on implementing RFC 9438 which will likely require more changes to the Controller trait.

Can we wait a bit more before merging this breaking change?

[Ralith]

I think we should merge this as soon as we get a non-breaking release out the door, but we can hold the breaking release.