Topic table extension

[haxxpop]

Implementing libp2p/specs#689 and libp2p/specs#699

Currently I decided not to implement the protocol violation part yet. When I receive an unsubstituted topic reference, currently I just treat it as it is and I don't close the stream or anything because I think it's possible that I will receive the unsubstituted topic reference by accident.

One corner case is because the hello packet handshake is not synchronized. It means that I can send a few more packets after my hello packet is sent but before I receive a hello packet from the other peer, so I cannot substitute the topic ref for those few packets.

We can make the hello packet handshake synchronous, but I think it requires a refactor.

[raulk]

Thanks for describing the edge case. A priori, it makes sense to not deem unsubstituted strings as a protocol violation.

The dual monodirectional streams approach has been a painpoint for a long time. AFAIR, the original rationale is that baseline libp2p has no way of knowing if the peer supports gossipsub, nor an easy to synchronize peers around a particular condition.

In practice, all libp2p users use identify and identify push, which advertises gossipsub. But we don't even need that. A simple rule would work:

The peer with the lowest peer ID is responsible for opening the duplex gossipsub stream (peer A). The receiving party (peer B) applies a timeout of 5 x RTT from libp2p connection establishment OR the first identify message listing A's protocols (whichever comes latest) to await the opening of the duplex stream. If no stream is opened, it assumes the peer does not want to interface over gossipsub.