Improvements related to Gossipsub 1.2

[diegomrsantos]

• Send IDONTWANT only to remote peers that support Gossipsub 1.2. or higher.
• Don't send a message as a response to an IWANT request if the remote peer has sent an IDONTWANT after the request.
• If the local peer has a pendingIWANT request from the remote peer P1 and in the meantime receives the message from another remote peer P2, send an IDONTWANT to peer P1. See https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.2.md#cancelling-iwant

[diegomrsantos]

@kaiserd the spec https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures says:

In flight IWANT requests, sent as a response to an IHAVE advertisement, are probabilistically tracked. For each IHAVE advertisement which elicits an IWANT request, the router tracks a random message ID within the advertised set. If the message is not received (from any peer) within a period of time, then a behavioural penalty is applied to the advertising peer through P₇. This measure helps protect against spam IHAVE floods by quickly flagging and graylisting peers who advertise bogus message IDs and/or do not follow up to the IWANT requests.

I believe this hasn't been implemented. #943 tried to do something similar, but it seems to me it goes against the spec. In order to implement https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.2.md#cancelling-iwant, we need to track in-flight IWANT messages. I am going to remove the last point here and create an issue for keeping track of in-flight IWANT messages.

See #1136.

[diegomrsantos]

I won't implement the second point either. We process IWANT messages synchronously and there won't be any opportunity for an IDONTWANT to arrive before we schedule the requested msg to be sent. It's better to just check the idontwants when we pop a msg from the non-prio queue.

See #1137.

[kaiserd]

Thanks for the update :).