only accept 0-RTT it the active_connection_id_limit didn't change

[marten-seemann]

As discovered by @rip-create-your-account in #3058 (comment), we need to check that the active_connection_id_limit transport parameter didn't change when accepting 0-RTT.

[codecov]

Codecov Report

Merging #3060 (35da77a) into master (2c45f2b) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3060   +/-   ##
=======================================
  Coverage   86.16%   86.16%           
=======================================
  Files         132      132           
  Lines        9355     9356    +1     
=======================================
+ Hits         8060     8061    +1     
  Misses        938      938           
  Partials      357      357           

Impacted Files	Coverage Δ
internal/wire/transport_parameters.go	89.08% <100.00%> (+0.05%)	⬆️

---

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 2c45f2b...35da77a. Read the comment docs.

[rip-create-your-account]

There's a tricky bug here which occurs when the client has already sent the NewConnectionIDFrames based on the 0-RTT (*TransportParameters).ActiveConnectionIDLimit. If the server has reduced its limit it will with this PR reject the 0-RTT handshake. When the client is notified that the 0-RTT handshake was rejected, it will drop the 0-RTT packets. This means that it will end up retransmitting the NewConnectionIDFrames of the 0-RTT packets, which is too many of them.

[marten-seemann]

@rip-create-your-account That's #2067.