- span for timers
- span for packets, this means we get path_id for some thing that are
not on the path of processing frames. the recv span can now lose
the path_id.
We can receive a PATH_ABANDON frame for which we do not yet have any
PathData. In this case we still want to abandon that path, and not
accidentally think we might be closing the last path.
- Adds a timer to resend another path challenge if the old one was lost
and the path isn't validated.
- The resent challenges now have different tokens. We keep track of all
of them to verify incoming path responses.
- The logic for when to send a path challenge is simplified to only send
challenges when `send_new_challenge` is set to `true` (instead of
triggering *always* when we're in path validation mode)
Since when we locally abandon a path we retire the CIDs for it, we can
then no longer send on it. We need to take this into account for
deciding which paths we want to send something on.
We do the CID check rather than just check of the path is in our
abandoned paths, since that is the check which is used lower down in
the loop as well. I think this is essentially the same state. Maybe
we could have done without the explicit set of abandoned paths as
separate state. I'm not sure.
It is possible that we receive retransmits of PATH_ABANDON frames. We
should handle those correctly and not panic.
We also should wait 3 * max PTO before we can decide that the remote
didn't abandon a path.
If a space had a tail-loss probe scheduled when the space is discarded
the poll_transmit function was still trying to send on it. Even
though there are no more crypto keys available for it.
This separates the path stats from the connection stats. The advantage
is that accessing the stats doesn't involve an allocation (for cloning
the map of the path stats).
Philipp Krüger