NetworkManager.StartServer() returns success when using uNet transport even when hostid is -1 and doesn't expose hostId either

[ashkan-saeedi-mazdeh]

Describe the bug
When using uNet transport, when you call StartServer in NetworkManager the returned task indicates success even when the port is used by another program and host creation in underlying transport fails. It should actually check the hostId and return failure if it is -1 or at least expose the hostId so we can check it in user code. Instead it just puts is in a local variable in the StartServer method and does nothing with it.
Many games listen to random ports in a range on the server and need to detect these failures.

To Reproduce
Steps to reproduce the behavior:

1. Open a simple MLAPI project in 1 build and an editor or two editors and run a scene with network manager
2. Click on StartServer button in inspector/do it programmatically
3. do the step 2's operation in the other distance and see the Transport LLAPI layer error in the console and the fact that MLAPI doesn't understand it failed
   Also observe that the returned task has no errors in its fields and reports success and hostId is not exposed anywhere

Actual outcome
Expected outcome
As described above, at least hostId should be exposed in the uNet transport class and also the failure should be understood by MLAPI and preferably the task returned from StartServer() should report it and the inner logic of the NetworkManager should not assume the server is running (whatever that means for its inner logic)

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Windows 10]
• Unity Version: [e.g. 2019.1]
• MLAPI Version: [e.g. v6.0.1]
• MLAPI Commit: [e.g. https://github.com/Unity-Technologies/com.unity.multiplayer.mlapi/commit/c102935df1d7e0928283b48948fe96e5d96dd961]

Additional context
I don't know if i need justifying this or not but in case I do.

A server startup can fail because the port is closed/another game server already is listening on or potentially other reasons later on. If it fails it should be somehow reported and taken into account. Even if this transport is temporary , still it should be working correctly and it is fairly easy to fix this.
For now we created a copy of it and exposed hostId and will use our own copy in our project but there should not be any need for this anyways.

Other reasons a StartServer/Listen might fail is invalid config or lack of resources for a transport , let's say later on you'll add the ability to pre-allocate buffers and the amount of memory available in the system is not enough and this method tries to allocate those buffers and fails. this should be reported back and dealt with.