feat: connection with ICE now gets target port from signalling node

[tegefaulkes]

Description

This PR tries to address the issue with #605. It's hard to say what the exact problem is but I'm assuming the forward connection isn't getting the most up to date information.

To attempt to fix this, this PR does the following.

1. The NodesConnectionSignalInitial returns the host and port of the target node from the perspective of the signalling node.
2. When doing ICE, the nodesConnectionSignalInitial is called returns the new address. The new port is then used when attempting the connection.

Issues Fixed

• Related Fix hole punching to work in both directions #605 - I'm not saying it's fixed because the current solution is based on conjecture. I'll need to do manual testing to know that it addressed the problem. And we'll need some test environments that provide different kinds of NATs to test against.
• Fixes NodesListConnections handler is randomly mapping IP addresses as IPv6 mapped IPv4 #614

Tasks

• 1. Fix the signalling process to return the target's port from the perspective of the signalling node
• 2. Fix IPv6 mapped IPv4 addresses being used in the NodeGraph. NodesListConnections handler is randomly mapping IP addresses as IPv6 mapped IPv4 #614

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[tegefaulkes]

I made a PR for this to review the changes. We need to coordinate the design between this and the decentralised signalling process that @CMCDragonkai is working on.

[ghost]

👇 Click on the image for a new way to code review

Legend

[CMCDragonkai]

If the connection worked from my end, it has to work from your end. The "strict nat" idea does not make sense here, because it's always a simultaneous interaction between both nodes.

The first step is to prove empirically if simultaneous interaction is happening. We know node 1 was able to connect to node 2. But node 2 was not able to connect to node 1 when it was initiating. So dump the logs for sending packets to each other.

[CMCDragonkai]

Also we cannot wait until we get a response from the signaller until we start a direct connection. We should start a direct connection, and also ask the signaller, and get a result if it is different, cancel the direct connection and start a new direct connection.

[CMCDragonkai]

Also during our initial test, it shouldn't be possible that our local node graph is already out of date, because we got that information about node 2, already from the same signaller.

[CMCDragonkai]

So I don't think the current PR fixes the problem. I suspect there's an issue with the signalling logic, we need logs here to show that there's simultaneous holepunching occurring with the correct ports.

[CMCDragonkai]

Consider this experiment, what if you initiated signalling and held off from direct connections. And then waited a long enough time for the other side to be attempting a direct connection, then start your own direct connection. Logically one would argue this is the equivalent of when the other side is just connecting to you via ICE.

[tegefaulkes]

After some extra testing I've determined that #614 also needs to be addressed in this PR to fix the issue.

[tegefaulkes]

I'm going to merge this now and move on to testing it. If the problem is resolved I'll close #605.