Observed behavior

When creating a connection to a local hostname, it's possible that the TcpClient created will grab the target port as its local port. This seems to result in a connection successfully being established and the client application grabbing the port, making it impossible for the nats server to ever start up later on using that port.

output of netstat (table format for readability):

netstat -abon | findstr 4222

Possible solutions:

• Use the TcpClient constructor with IPEndpoint input (TcpClient)
• After constructing the TcpClient, modify the internal socket (TcpClient.Client) to exclude the target port from being used as the local endpoint's port

Comments:
While I'm not 100% certain on the root cause of this, the above description is my best educated guess on why this would happen.
I've only noticed it on dev machines that run the host process, which tries to connect every 1 second to NATS, and while the target local nats-server, is not running.

This results in not being able to start the local nats-server anymore.

I know it's very niche but it's better if its noted down at least, even if there's no intent to fix it or spend time on it.

Expected behavior

The NATS client does not use the target endpoint's port as the local endpoint's when connecting with a local endpoint

Server and client version

Server version not relevant.
client version: 1.1.1

Host environment

Running on Windows 10 Enterprise, loading the NATS client library as .netstandard 2.0 from a .NET 6.0 host process.

Steps to reproduce

Continually call Connect until you randomly get the target's endpoint port as your local endpoint's port.