Discover External IP address via PONG messages

[pipermerriam]

What was wrong?

Each PONG message contains an external IP address that the sender is claiming is our external IP.

This information can be used in combination with some basic heuristics to identify our external ip address.

How can it be fixed?

We will have to use a heuristic since 1) this information is unverifiable and 2) different peers might have a different view of what our IP address might be.

We should aggregate votes for this in a simple service that listens to all the incoming PONG messages. This service will benefit from having contextual information about the peer connections such as whether they were dial-out or dial-in, whether they are trusted such as bootnode addresses.

Likely only viable once our view of the network contains a sufficiently large number of peers.

[pipermerriam]

@lithp I think this might be a decent next issue to get worked on.

I think this needs to fit into a larger framework of how we decide on what external IP address to populate our ENR record with. I think we have the following sources for IP addresses.

1. returned by UPnP during port mapping
2. Inspecting networking devices via netifaces library (used in the upnp library)
3. specified via CLI --listen-address
4. Pong messages

I think the priority order for these should be:

1. --listen-address trumps all
2. UPnP
3. Pong messages
4. netifaces data (pulling IP from networking devices)

This also needs to be generic enough to work with both v5 and v5.1.