Remove incorrect spurious migration handling

[Ralith]

This case is handled by the usual path validation timeout, and by the ACK elicited from the peer by a PATH_CHALLENGE on a legitimate path.

Context:
§9.3.2:

To protect the connection from failing due to such a spurious
migration, an endpoint MUST revert to using the last validated peer
address when validation of a new peer address fails.

§9.3.3:

In response to an apparent migration, endpoints MUST validate the
previously active path using a PATH_CHALLENGE frame. This induces
the sending of new packets on that path.

§1.2:

Ack-eliciting packet: A QUIC packet that contains frames other than
ACK, PADDING, and CONNECTION_CLOSE.

§9.1

PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames
are "probing frames", and all other frames are "non-probing frames".

§9.2

An endpoint can migrate a connection to a new local address by
sending packets containing non-probing frames from that address.

So if a spurious migration occurs, we (already) send a PATH_CHALLENGE on the previous path, the peer ACKs it, and that non-probing packet triggers a new migration back to the legitimate path. Or, alternatively, the path validation timer expires for the new path and we revert to the legitimate one.

Thanks to @Matthias247 for helping identify this!

[djc]

Nice work!