Handle /quic and /ws in NAT mappings

[Stebalien]

The mappings report /ip{4,6}/.../{udp,tcp}/... without the /quic or /ws suffix. This means that, while we do map these protocols, we don't actually advertise the correct addresses.

We need to:

1. Fix BasicHost.AllAddrs to pick the right mappings based on the internal port, not the full address.
2. Fix go-libp2p-nat to only accept tcp/udp addresses (quic, ws, etc. don't make any sense at the NAT level anyways). Really, we may want to switch the interfaces to protocol + port instead of multiaddr but we can do that later.

[overbool]

@Stebalien Did you mean that /ip4/.../tcp/4001 and /ip4/.../tcp/4001/ws will generate two mappings, but latter was redundant？

[vyzo]

Fix go-libp2p-nat to only accept tcp/udp addresses (quic, ws, etc. don't make any sense at the NAT level anyways).

But we do want to open port mappings in this case too.

[overbool]

/ip4/.../tcp/4001/ws is redundant, because tcp+4001 had been mapped (/ip4/.../tcp/4001). However, /ip4/.../tcp/4002/ws will be mapped, because tcp+4002 is a new mapping.

just like:

Really, we may want to switch the interfaces to protocol + port instead of multiaddr but we can do that later.

[Stebalien]

No. We actually can't listen on both /ip4/.../tcp/4001 and /ip4/.../tcp/4001/ws. Those two listeners would conflict.

The issue is much simpler:

1. When we see /ip4/.../tcp/4002/ws, we ask the NAT manager to map it. This works as intended.
2. When we advertise our addresses, we ask the NAT manager which addresses we have mapped. Unfortunately, these addresses don't include the /ws part because the NAT manager really only cares about the IP/port/protocol tripple.

This means that even though we might be listening on /ip4/.../tcp/4002/ws, we'll end up advertising /ip4/.../tcp/4002 (no /ws).

[vyzo]

that's definitely a bug!