Tracer panic with large initial_sequence and delayed TCP probes

[fujiapple852]

When running with a large initial_sequence, such as 64000, for TCP tracing, the tracer can panic if a delayed TCP probe response from a prior round is received.

This happens because the check to determine if a given sequence is in the current round check if difference between the sequence (the sequence number of the probe response) and the round_sequence (the sequence number for the first probe in the round) is less than the BUFFER_SIZE (currently 1024):

/// Is `sequence` in the current round?
pub fn in_round(&self, sequence: Sequence) -> bool {
    sequence >= self.round_sequence && sequence.0 - self.round_sequence.0 < BUFFER_SIZE
}

For example, if initial_sequence is 64000 and round_sequence is 64055, a delayed probe response from a prior round, such as sequence 64491, will incorrect pass the above check.

This can manifest itself in various ways, typically a panic in the below code in send_request but it can, by luck, pass this code and manifest itself later on such as in Trace::update_from_probe.

let can_send_ttl = if let Some(target_ttl) = st.target_ttl() {
    st.ttl() <= target_ttl
} else {
    st.ttl() - st.max_received_ttl().unwrap_or_default() < TimeToLive(self.max_inflight.0)
};

The solution is to restrict the maximum allowed initial_sequence to u16::MAX - 2 * BUFFER_SIZE to ensure sequence numbers from the immediate prior round will be correctly discarded by the in_round check. This fix will not guard against the extreme case of a delayed from two rounds prior.

[fujiapple852]

cc @zarkdav