Implement modern Slow Start algorithm

[omansfeld]

After modernizing our CUBIC implementation in #2535 we should update our Slow Start algorithm.

https://github.com/mozilla/neqo/issues/1912#issuecomment-2604867235

As part of this, we should also look into implementing HyStart.

https://github.com/mozilla/neqo/issues/1912#issuecomment-2743440297

This one might be an alternative to HyStart: datatracker.ietf.org/doc/draft-chung-ccwg-search

Currently we implement standard TCP style slow start as described in RFC 9002: QUIC Loss Detection and Congestion Control. This grows the cwnd exponentially during slow start and can thus significantly overshoot the ideal rate, causing significant packet loss. See e.g. the simulation below:

HyStart++ uses a RTT heuristic to exit Slow Start before packet loss occurs and then adds a second Conservative Slow Start (CSS) phase to probe towards the ideal sending rate. This way it mitigates packet loss and retransmissions and improves goodput. E.g. the Linux Kernel implements HyStart++ with CUBIC for it's TCP stack (https://github.com/torvalds/linux/blob/d7ee5bdce7892643409dea7266c34977e651b479/net/ipv4/tcp_cubic.c#L13C4-L13C9).

SEARCH (Slow start Exit At Right CHokepoint) is a more experimental TCP/QUIC Slow Start algorithm that aims to exit Slow Start after the congestion point is reached but before packet loss occurs (so basically at the perfect sending rate) which should theoretically make it more efficient then HyStart++. It uses a heuristic comparing acked delivered bytes to expected delivered bytes.

I will be writing my bachelor thesis on comparing HyStart++ and SEARCH in Firefox during Q4 2025 and will tackle this work item as part of that.