fix: bug with GPRC client call through proxy

[tegefaulkes]

Description

This PR is to address the issue with #369 and other small fixes.

This is basically the fix:

      this.tlsSocket.once('data', () => {
        this.serverSocket.pipe(this.tlsSocket as TLSSocket, { end: false });
      });

We couldn't get pause or cork to work. So now we only start piping the server socket to the tls socket on the reverse side upon first receiving data.

Issues Fixed

• Fixes GRPC call failure when multiple nodes connecting to 1 seed node. #369

Tasks

1. fix the RST_stream GRPC bug. Do this by delaying any response through the proxy till after we receive the MAGIC frame.
2. Add in a check for handleConnectForward for the wild card addresses since they should not be connectable. - this could be done in Proxy.establishConnectionForward because it is used by both handleConnectForward and openConnectionForward, and it would throw a specific exception for this. Have a look at src/network/errors.ts to see what is acceptable.
3. Add additional tests for this in Proxy.test.ts
4. Ensure that NodeConnection.name is embedded in the NodeConnection logger.
5. update logging in NodeConnectionManager to be less confusing when creating and using connections.
6. test for if the proxy connections are established first and then client connects.

Final checklist

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

[CMCDragonkai]

It turns out that networkUtils.resolvesZeroIP is used by network/Connection.ts to resolve zero IPs to localhost. This works, but all our logging gets confusing.

So to avoid future confusion, then we should just be preventing any usage of zero IP by using a isHostWildcard check can be done.

The question is where should this be done? During the construction of Connection or done also in the Proxy where connections are being opened forward and reverse and as well as via the CONNECT handler.

[CMCDragonkai]

@emmacasolin if you do the above simple fix, does it solve your problem from before?

[emmacasolin]

@emmacasolin if you do the above simple fix, does it solve your problem from before?

I haven't tested it using namespaces yet, however @tegefaulkes has said that it fixes the case that we were using for testing before inside noNAT.test.ts #369 (comment)

[emmacasolin]

@emmacasolin if you do the above simple fix, does it solve your problem from before?

I haven't tested it using namespaces yet, however @tegefaulkes has said that it fixes the case that we were using for testing before inside noNAT.test.ts #369 (comment)

Confirming that this fix also works for agents/seed nodes that are in different namespaces.