Peer routing fails for peers behind NAT (with /p2p-circuit)

[2color]

What's wrong

When running someguy with a public IP that isn't dialable (due to firewall or whatnot) and trying to resolve a PeerID to multiaddrs for a peer behind NAT, someguy doesn't return any results.

This was observed in the delegated routing endpoint, which consistently returns empty results for such peers.

This seems to be a recent regression, likely as part of the 0.4.0

Related issues

My hunch is that this is due to libp2p/go-libp2p#2913 based on some testing trying to resolve my own peerID (which is behind NAT). By enabling hole punching logging (GOLOG_LOG_LEVEL="p2p-holepunch=debug) I was able to see ("error": "failed to open hole-punching stream: failed to negotiate protocol: protocols not supported: [/libp2p/dcutr]"}) errors

[2color]

After some investigation with the help of @sukunrt, this bug is likely due to a change in go-libp2p libp2p/go-libp2p#2696 which deprecated the CanConnect Network state along with the dependency on go-libp2p-kad-dht which was still depending on that value.

I've opened a PR in the go-libp2p-kad-dht repo to fix this.

[2color]

We have pushed a workaround fix for the public delegated routing endpoint by allowing the someguy libp2p host to bind to a specific port, which if is on a public interface, avoids the bugs around hole punching with direct dial backs (which were blocked to to dynamic ports blocked by firewall)

#79