Reset spin bit when probing

[MikeBishop]

This is likely a case of "we know what we meant," but....

Section 17.3.1 says that the spin bit can be enabled/disabled on a per-connection or per-CID basis, and that:

An endpoint resets its spin value to zero when sending the first packet of a given connection with a new connection ID. This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change.

However, a literal reading of this suggests that a client which sets the spin bit on a per-connection basis will revert the spin bit on the main path to zero whenever it uses a new CID to probe on an alternate path. It also has implications for an implementation that uses many active CIDs at once.

One resolution is that the current state of the spin bit is maintained on a per-CID basis, and that the CID begins at zero for each CID. However, for the client using many CIDs at once, that then begs the question of which of the peer's CIDs are being reflected back to it.

I think that what we actually mean here is two-fold:

• The current state of the spin bit is maintained on a per-path basis, and is initialized to zero for each path.
• The current state of the spin bit is reset to zero whenever the CID being used on a path changes, no matter how frequently that is.

[larseggert]

I think what you summarize in the bullets is indeed what was intended. @britram?