Support for blocking logically inbound connections

go-libp2p has a ConnectionGater interface that allows the user to control the types of inbound and outbound connections that a given host can make. However, as far as I can tell these limitations are based at the Transport level which does not interact nicely with DCuTR.

I suspect there is a class of users (perhaps most of them) that when blocking inbound connections what they really mean to be doing is blocking logically inbound connections rather than ones that are mechanically inbound. An example use case here might be a user running a libp2p node on a public IP address that wants to fetch data from many peers (including those behind NATs which will do DCuTR dialback) but does not want to communicate with any peers other than those it has reached out to.

In a mode where there is support for blocking logically inbound connections we would end up with the following: ( ❌ means we want a failure, ✅ means we want a success)

• Someone dialing me over tcp ❌
• Me dialing someone over tcp ✅
• Someone dialing me over tcp using a DCuTR dialback after I dialed them ✅
• Someone dialing me via a relay and getting me to connect to them via a DCuTR dialback ❌

IIUC this contrasts with using the ConnectionGater to deny all InterceptAccept responses since it would give the correct result for 1, 2 and 4 but an incorrect result for 3.

Start by tracing the ConnectionGater interface, its InterceptAccept path, and how DCuTR dialback connections are classified. Compare the four connection cases in the issue and define behavior that distinguishes logically inbound connections from mechanically inbound ones; done means those cases produce the requested success or failure outcomes.