ConnectionGater.InterceptAccept encourages acting upon unauthenticated information

InterceptAccept allows rejecting of connections before completion of the libp2p handshake. In the case of TCP, this means right after the 3-way-handshake.

This allows a man-on-the-side attacker to inject a DISCONNECT message. More importantly, if the endpoint that initiated the connection interprets this message as "I was blacklisted. No need to retry a connection to this peer for the next x days", the attacker would have succeeded in effectively blocking libp2p for a long time period.

While an attacker can of course always inject a TCP Reset (this attacks, and countless variants thereof, are the most common way nation-state firewalls work), the interpretation of this will likely be different from the interpretation of a DISCONNECT.
In the case of QUIC, it will soon be possible to perform a handshake that is not susceptible to injection attacks at all. All we need is support for ECH (Encrypted Client Hello), which is still being developed by the IETF.

Unfortunately, deciding to not act upon unauthenticated information means that rejecting a connection would only be possible after completing the handshake. This is not a pleasant outcome, as handshakes aren't computationally cheap, and they take one RTT. It seems like this is a price we have to pay to make the protocol more robust against censorship.

cc @aarshkshah1992

Start at ConnectionGater.InterceptAccept and trace how TCP and QUIC connection rejection is handled before and after the libp2p handshake. Review how a DISCONNECT message is interpreted by the initiating endpoint, and define the desired behavior for unauthenticated rejection and completed handshakes. Done requires an agreed protocol behavior and corresponding validation.