Attempt to read ipv4-mapped ipv6 to ipv4 if possible

[quentinlesceller]

A potential additional operation during read some maybe not the best idea.

[antiochp]

Majority of our peer addresses are currently ipv4 and this additional step is only used for ipv6 - so I think that is probably fine.
I think this makes sense - but need to think it through a bit more.

[antiochp]

We need to work out where these ipv6 addresses are coming from as well.

1. outbound peer connection (remote peer accepts both ipv4/ipv6 so we see a mapped version)
2. inbound peer connection (peer connects to us, peer configured for both ipv4/ipv6)
3. via a broadcast list of peer addresses?

I'm not even sure we would use this code path if it was (1) or (2) as we read the peer address via the underlying tcp connection? At least for one of those, maybe not the other.

[quentinlesceller]

Only case that I have seen is 3. This PR do the job in that case.

[antiochp]

So I think we also need similar logic when we compare ip addrs when looking to see if we are already connected to a peer.
We do this when accepting a connection (and maybe when trying to connect). If we are already connected then we want to identify the duplicate attempt and close the new connection. And I believe we do this based on a comparison of the ip address.

[antiochp]

Related - #3208.

[antiochp]

If we can get to point where we are confident this improves the overall situation regarding ipv4-mapped addresses on the network then we should aim to get this merged in for a potential 3.1.0 release.

[antiochp]

I think this in combination with #3225 is a good idea.

👍