TCP flow state tracking should be lockless, if possible #837
Description
For TCP flows, once a fastpath entry has been acquired we need to update the TCP state based on the flags seen in a packet. Today this is guarded using a KMutex<T>, which ends up as a place where contention can arise for a single flow. Mainly, this is because the Rx packet processing and Tx packet processing are going to be happening on different threads unless we get very lucky with squeue bindings.
Outright removing the TCP state gets us around 500 Mbps, but I think in general we do want to keep it in place. My thinking here is that most state transitions are going to be trivial: e.g., moving from TcpState::Established to itself, and incrememting some counters. Everything else could be probably handled by computing the transform, performing a compare-and-swap between the old and target states, and then looping those steps if the comparison fails.