Add rtt estimator snapshots, if more accurate rtt analysis is demanded

[StarStarJ]

Motivation:

This would allow users to get more accurate RTT information for specific needs like the range of jitter in the rtt. Additionally it was not possible to request the other member variables of the rtt estimator before. (https://github.com/quinn-rs/quinn/issues/931#issuecomment-2185200803)

This can be useful for more accurate timer tracking between server & client on less stable connections (or a dos attack on the server or similar things)

For example here, we see that the smoothed is kinda outdated

[quinn/examples/client.rs:147:5] conn.rtt_estimator_snapshot() = RttEstimatorSnapshot {
    latest: 126.72µs,
    smoothed: Some(
        391.996µs,
    ),
    var: 237.002µs,
    min: 126.72µs,
}

On linux you can also use: sudo tc qdisc add dev lo root netem delay 300ms 300ms

to simulate a massive lag, and then the smooth rtt value will only provide a rough estimate of the average latency, not about the range of the rtts.

If you think a whole snapshot is too much, I'd already be happy to get access to just the latest member of the rtt estimator, so I could at least fire up my own logic without applying a custom congestion controller.

[StarStarJ]

A little more detailed usecase:

I run logic on my server & client and want this logic to be kept in sync as much as possible. so the client uses the max rtt to simulate the maximum time a packet would need to arrive on the server and a response goes back to the client.

Additionally the client must detect network lags as quick as possible, so i has to judge if the timing of the packet lies in between the rtt range and apply actions if not (e.g. adjust the timer more quickly).

I could ofc run a custom timer by sending additional packets, but since (all?) packets in quic must be ack'd I kinda get this for free now anyway.

I already did tests locally, and it worked quite well.

(The application is a real-time app, so high sample rates are expected anyway)

[StarStarJ]

I just included timing information into some of my packets that are send & recv by the client, which is very accurate now.

Since I am probably the only one with my use case, I don't want to bother you with this anymore.

Thanks again for this nice lib.

[Ralith]

I'm glad you found a satisfactory solution! I'm not categorically opposed to exposing more granular data, but indeed it's a difficult API design problem to come up with something that's broadly useful without being overly complex.