TransportListenInfo: Add portRange (deprecate worker port range)

[ibc]

Details

• New optional portRange field (an object with min and max keys) has been added in TransportListenInfo, so it's available in router.createWebRtcTransport(), router.createPlainTransport(), router.createPipeTransport() and worker.createWebRtcServer() methods.
• If portRange is given, then a free random port in that range (and given ip and protocol) will be chosen.
• This feature deprecates worker ports range (rtcMinPort and rtcMaxPort in WorkerSettings given to createWorker() method). Rationale is that it doesn't make any sense to have a unique port range for different listening IPs (for example: an app may want to use different port ranges for public connections (public internet) and private connections (private network).

TODO

• Documentation in website and proper announcement.

[ibc]

@jmillan, minPort and maxPort now moved to portRange.

[CosmosisT]

Why not allowedPorts and provide ability for min/max and static ports. That way everyone is settled. I would assume if isolated processes are ran the min/max range would still be affective skipping used ports for an available one when initiating connections.

The parameter would look a little like this allowedPorts: {min: 20000, max: 30000, static:[443, 3923, 10293]}

This way no matter the setup it's simplified and in one spot and for people who want specifics between TCP/UDP connections this would suffice.

[ibc]

We allow passing a static port (so the app must manage ports by itself) or a port range. IMHO is more than enough. In addition the PortRange C++ class is optimized to avoid trying already used ports.

Also, it doesn't make sense that the app passes some static ports plus a port range. If the app passes a static port then the app is supposed to manage ports. mediasoup is not gonna try first your "maybe available or not" static ports and then, of all fail, choose a random one in the given range. It doesn't make sense.