Maintain in-flight counters separately per path

[Ralith]

Fixes #1775, theoretically. @nemethf can you confirm?

RFC9000 §9.4:

The capacity available on the new path might not be the same as the old path. Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path.

We accomplish this by tracking the first packet number on each path, which allows the logic that removes acked/lost packets from congestion control counters to determine which, if any, known path a packet was sent on.

[nemethf]

Fixes #1775, theoretically. @nemethf can you confirm?

Yes, it does solve my original issue and the traffic quickly migrates to the new path. Thank you.

---

Looking at the captured traffic, I was a bit surprised:

 No. -     Time -             Source -           Dest -             Proto -        Length -         Info -
 278       2.897193           10.0.2.1           10.0.3.1           QUIC           78               Protected Payload (KP0), DCID=7abe9d2420aaddb1, PKN: 101, PING, PADDING
 279       2.907467           10.0.3.1           10.0.1.1           QUIC           1248             Protected Payload (KP0), DCID=033dda038eeebb0b, PKN: 219, PC, PADDING
 280       2.907472           10.0.3.1           10.0.2.1           HTTP3          1248             Protected Payload (KP0), DCID=033dda038eeebb0b, PKN: 220, ACK_ECN, PC, RC, STREAM(3)

In other words the server sends payload alongside with the PATH_CHALLENGE. I did not know this was possible, but RFC9000 permits it: " An endpoint MAY send data to an unvalidated peer address, but it MUST protect against potential attacks as described in Sections 9.3.1 and 9.3.2." So it's all good. Thanks again.

[Ralith]

Yep, that's the intended behavior. Separate logic applies an anti-amplification budget to all unvalidated paths to prevent this from being too much of an amplification hazard if someone attempts the rather esoteric off-path packet forwarding attack. Thanks for confirming!

[djc]

Nice!