use a monotonous timer

[marten-seemann]

Fixes #3567. Fixes #3179.

There's no point in having the timer fire multiple times for the same
timestamp. By using a monotonous timer we avoid busy-looping in cases where the
timer fires, but we can't actually send a packet.

[codecov]

Codecov Report

Base: 85.50% // Head: 85.73% // Increases project coverage by +0.23% 🎉

Coverage data is based on head (11cbf1e) compared to base (424a663).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3570      +/-   ##
==========================================
+ Coverage   85.50%   85.73%   +0.23%     
==========================================
  Files         139      140       +1     
  Lines       10244    10634     +390     
==========================================
+ Hits         8759     9117     +358     
- Misses       1103     1123      +20     
- Partials      382      394      +12     

Impacted Files	Coverage Δ
connection.go	76.42% <100.00%> (-0.02%)	⬇️
connection_timer.go	100.00% <100.00%> (ø)
internal/utils/timer.go	100.00% <100.00%> (ø)
internal/ackhandler/received_packet_handler.go	74.42% <0.00%> (-1.34%)	⬇️
datagram_queue.go	90.77% <0.00%> (-0.72%)	⬇️
qlog/event.go	98.55% <0.00%> (+0.43%)	⬆️
qlog/qlog.go	92.58% <0.00%> (+1.43%)	⬆️
packet_packer.go	89.22% <0.00%> (+1.45%)	⬆️
internal/ackhandler/received_packet_tracker.go	88.10% <0.00%> (+1.89%)	⬆️
http3/server.go	77.40% <0.00%> (+3.10%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[lucas-clemente]

This assumes that we never rely on this behavior to not get stuck. I guess the test suite is good enough for that…? :/

[marten-seemann]

This assumes that we never rely on this behavior to not get stuck. I guess the test suite is good enough for that…? :/

The assumption is that when any timer fires at t > t', all the actions that should have been performed at t' will get executed. This has been our general design, since with a timer, you can never be sure when exactly it fires (it may fire at any time after the time you set it for).

That said, I'd consider this PR an improvement, because even if we miss something here, worst case is that that one connection is eventually killed by the idle timeout. Previously, we'd effectively kill the node by busy-looping.