feat: connection gater

[achingbrain]

Port of https://github.com/libp2p/go-libp2p-core/blob/master/connmgr/gater.go

Fixes: #175
Refs: #744
Refs: #769

Follows on from #987 - that PR does not allow maintainer commits so I've created a new one.

[achingbrain]

I know this is a port of the related go-libp2p functionality and that's where the nomenclature comes from, but I would much rather test against positive action than negative action or ambiguous sentiment.

interceptPeerDial to me does not say "return false to allow dialling a peer", it says 'do something with the peer dial'. Instead I feel something like allowPeerDial which returns true to allow dialling a peer would be much simpler to reason about.

So, all of these would return true to allow the operation to continue:

interceptPeerDial -> allowDialPeer
interceptAddrDial -> allowDialMultiaddr
interceptAccept -> acceptConnection
interceptSecured -> acceptSecuredConnection
interceptUpgraded -> acceptUpgradedConnection

I also see that we call interceptAddrDial before adding a multiaddr for a peer to the addressbook - this is not doing what the method says it is doing. Suggest adding a allowStoreMultiaddrForPeer method or similar.

What do you think @wemeetagain @greenSnot ?

[wemeetagain]

@achingbrain

I agree with your renaming thoughts.

Same with allowStoreMultiaddrForPeer. Although, this one feels strange, like the current implementation is incomplete or should be rethought. The flag only currently has effect in a single place in the dialer, and the multiaddr can still be added via peerStore.addressBook.add(peer, multiaddr), and this occurs in several other places.

[achingbrain]

Good point, that filtering might be better done in the address book itself rather than just in the dialler.

[wemeetagain]

lgtm 👍

[greenSnot]

lgtm, hooray~