feat: Allow Unity Transport to bind clients to a specific port

[simon-lemay-unity]

Purpose of this PR

Currently Unity Transport always binds clients to an ephemeral port. This is what you want pretty much all of the time, but sometimes there are circumstances that require binding to a specific port. For example if you're in a particularly restrictive environment where your IT team requires knowing the source ports of outbound connections. Or if you're setting up NAT punch-through and need to be able to reach the client on a known port.

This PR adds the possibility of binding to a specific port on the client by adding an extra field to the UnityTransport.ConnectionAddressData structure. For users the API looks like this:

var transport = (UnityTransport)NetworkManager.Singleton.NetworkConfig.NetworkTransport;
transport.ConnectionData.ClientBindPort = 12345;

// Then connect your client as usual.

I haven't added this new possibility to the UI, and I haven't added new utility SetConnectionData methods that accepts this port as a new parameter. The rationale being that most users do not need to modify this. And putting it in the UI in particular could easily have users thinking that they need to put the server's port in there, which can easily lead to issues with port reuse if you start multiple clients.

I also modified the documentation of SetConnectionData to make the role of the listen endpoint parameter clearer.

Changelog

• Added: It is now possible to control which port clients will bind to using the UnityTransport.ConnectionData.ClientBindPort field. If not set, clients will bind to an ephemeral port (same as before this change).

Jira ticket

None. This is coming from a user request on the discussions website.

Documentation

• Includes edits to existing public API documentation.

Testing & QA

Functional Testing

Manual testing :

• Manual testing done

Automated tests:

• Covered by existing automated tests
• Covered by new automated tests

Does the change require QA team to:

• Review automated tests?
• Execute manual tests?
• Provide feedback about the PR?

Backports

Could technically be backported, but I won't bother unless a user requests it specifically.

[michalChrobot]

Heyo, everything looks super nice from my side but I guess we should also bump NGO version to 2.8.0 (new API added).

You can notice that Vetting test passes and this is because of known limitation --> We branched off for the release of NGOv2.7.0 and version on the develop-2.0.0 branch was updated HERE to reflect current package state BUT since we are still in the process of releasing the vetting test is actually comparing local version (2.7.1) with last released version (2.6.0) so addition of new API is allowed by this check

If you will merge this PR without bumping the package version then as soon as we will release 2.7.0 we will start getting Vetting test failures about this API addition (test will compare 2.7.1 with 2.7.0 and will scream about that adding new API requires minor bump)

So overall, a known edge case but we should bump the version to avoid getting this error after the release. Let me know if this makes sense (@EmandM @NoelStephensUnity just a reminder so you are aware of this edge case)

[simon-lemay-unity]

@michalChrobot Bumped the version of the package to 2.8.0.

[NoelStephensUnity]

Thank you @simon-lemay-unity for updating this!