declare the handshake confirmed when receiving an ACK for a 1-RTT packet

[marten-seemann]

... on the client side. Both the receipt of HANDSHAKE_DONE and the receipt of an ACK for a 1-RTT packet are sufficient for declaring confirmation of the handshake.

Fixes #3144. @rip-create-your-account

[codecov]

Codecov Report

Merging #3148 (17d9860) into master (3138a45) will increase coverage by 0.03%.
The diff coverage is 91.67%.

❗ Current head 17d9860 differs from pull request most recent head 9e9d4a4. Consider uploading reports for the commit 9e9d4a4 to get more accurate results

@@            Coverage Diff             @@
##           master    #3148      +/-   ##
==========================================
+ Coverage   85.38%   85.41%   +0.03%     
==========================================
  Files         131      131              
  Lines        9684     9690       +6     
==========================================
+ Hits         8268     8276       +8     
+ Misses       1046     1044       -2     
  Partials      370      370              

Impacted Files	Coverage Δ
internal/ackhandler/sent_packet_handler.go	77.70% <85.71%> (+0.16%)	⬆️
session.go	77.36% <100.00%> (+0.16%)	⬆️
internal/utils/rand.go	75.00% <0.00%> (+12.50%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3138a45...9e9d4a4. Read the comment docs.

[rip-create-your-account]

SentPacketHandler stores only ack-eliciting packets so an opportunity to confirm the handshake could be missed. Or is there a reason to not confirm handshake with packets that are not ack-eliciting? The suggested implementation allows it.

Also with the current implementation, I think the comments on the SentPacketHandler interface like /* contained 1-RTT packet */ should be /* contained 1-RTT ack-eliciting packet */ just to be exact.

[marten-seemann]

Or is there a reason to not confirm handshake with packets that are not ack-eliciting?

@rip-create-your-account we don't save them in the packet history.