Min port is not respected for randomly assigned ports

[SeriousBug]

The min port number is applied when the client tries to request a specific port, but not when the port is randomly assigned (when client sends port 0).

To reproduce the error:

$ bore server --min-port 65530
2023-02-12T17:49:49.232469Z  INFO bore_cli::server: server listening addr=0.0.0.0:7835
2023-02-12T17:50:08.387048Z  INFO control{addr=127.0.0.1:55590}: bore_cli::server: incoming connection
2023-02-12T17:50:08.387064Z  INFO control{addr=127.0.0.1:55590}: bore_cli::server: new client port=0

# On a different terminal
$ bore local 8000 --to localhost
2023-02-12T17:50:08.387095Z  INFO bore_cli::client: connected to server remote_port=37941
2023-02-12T17:50:08.387102Z  INFO bore_cli::client: listening at localhost:37941

The randomly assigned port is below the configured minimum.

Looking at the codebase, TcpListener doesn't seem to have any interface for specifying a minimum port for randomly assigned ports. A solution would likely have to randomly pick ports within the server and not leave it to the OS by setting it to 0.

[ekzhang]

You're right, it's not respected for randomly selected ports. I'll look at merging #28 later when I have time.

[bear0330]

I also need that feature. Because I can only open some ports on my server. Thanks to your great work. Bore is fantastic.

[msft-bnorick]

You're right, it's not respected for randomly selected ports. I'll look at merging #28 later when I have time.

I made a new PR, #78, which supports both min and max ports and addresses your concern from #28 about sequentially trying to bind every port in the range. Please take a look.

[msft-bnorick]

I also need that feature. Because I can only open some ports on my server. Thanks to your great work. Bore is fantastic.

In case this is still something you need, you can consider compiling from this branch until the corresponding PR is merged. It's as simple as cargo build --all-features --release.