Don't try to use a fixed port in test_server_config_default

[msullivan]

We had a flake regarding this.

(At least on my machine?), linux never randomly assigns an even
numbered port, so probably the flake collided with something external
specifically looking for it?

The find_available_port mechanism is fundamentally racy, of course;
the port could be allocated by someone else immediately, and in
testing I did manage to observe cycle lengths as short as 2 before a
reuse.

Possibly these tests should just have a big hammer
@retry_failed_test(3) decorator around them or something, but I am
reluctant to introduce this because I fear we will use it instead of
writing proper tests.

(Most tests don't have as good an excuse for flakiness as needing to
allocate a shared resource in a 16-bit namespace).

[1st1]

@fantix why are we jumping through hoops here with 1024 and a while loop? Why not always just bind to 0?

[1st1]

I see the new logic introduced in dea17d4

[msullivan]

Oh, right, it was because there used to be a bug where ports greater than 32767 broke: #6194

[msullivan]

Also, you can link to code snippets and diff snippets in github; no need to resort to screenshots.

[1st1]

Oh, right, it was because there used to be a bug where ports greater than 32767 broke: #6194

The way how I'd do this is to try binding at least one port through bind(0), and if that returns high enough ports then resort to do a while loop.

In any case, I don't quite understand how your PR fixes the problem. Are we running out of ports < 50000?

[msullivan]

For the flake I saw, I kind of suspect that it collided with something else on the system trying to use port 50000, though I'm not really sure.

[msullivan]

I'm not actually sure how much this will actually mitigate the flake, but it's a general cleanup at least.

[msullivan]

Could someone approve this? It's a strict cleanup, even if it is only marginally likely to help the flakiness here