GEODE-9725: Remove membership port range feature from AvailablePort

[demery-pivotal]

AvailablePort and AvailablePortHelper have methods to retrieve an
"available" port from the membership port range. This feature is both
unnecessary and inherently unreliable.

INHERENTLY UNRELIABLE

The default membership port range overlaps each OS's ephemeral port
range. An ephemeral port deemed to be "available" by one of these
methods can be put into use by another process even before the method
returns. It is not safe to rely on such a port to remain available after
it is checked.

UNNECESSARY

Currently the only callers that request ports from the membership port
range are two tests in DistributedSystemDUnitTest. In each case, the
test uses the returned ports to set the membership port range for a
member. There is no need for the ports to come from any particular
range.

There are no other uses of this feature, either in the product or in
tests.

SOLUTION

Remove the "membership port range" feature from AvailablePort and
AvailablePortHelper.

Change DistributedSystemDUnitTest to get available ports from the
"available port range." This range is safe to use (assuming all other
concurrently-running tests are well-behaved).

[demery-pivotal]

I'm confident that the distributed test failure in QueryConfigurationServiceConstraintsDistributedTest is unrelated to my changes. The AuthenticationRequiredException's initial cause has a stack trace similar to the one in https://issues.apache.org/jira/browse/GEODE-9689.

[Bill]

Shouldn't getRandomAvailablePort(int protocol) be removed?

I think the only use of this method is in tests.

[demery-pivotal]

Perhaps, in another PR.

[Bill]

What about AvailablePort.main()? Is that entrypoint used anywhere?

[Bill]

I understand your "INHERENTLY UNRELIABLE" analysis. What I don't understand is: why does that argument apply only to ports in the membership port range? Seems to me that any method that purports to return an "available port range" is misguided. What am I missing here?

[demery-pivotal]

I understand your "INHERENTLY UNRELIABLE" analysis. What I don't understand is: why does that argument apply only to ports in the membership port range? Seems to me that any method that purports to return an "available port range" is misguided. What am I missing here?

The key is that the membership port range overlaps with each operating system's ephemeral port range. The operating system is free to give those ports to anyone who asks for an ephemeral port. Many tests launch members in a way that uses ephemeral ports, making the risk significantly higher in CI than in normal use.

A port in any other range (such as the "available port" range) is likely to be put into use only if a caller specifically asks for that port. We have a fairly strong convention to use those ports only after checking their availability. And the way tests check availability significantly minimizes the risk of conflict. The risk is minimized by the build system allocating a distinct range of ports to each concurrently-executing test JVM, and by AvailablePortHelper allocating those ports round-robin instead of randomly.

[demery-pivotal]

What about AvailablePort.main()? Is that entrypoint used anywhere?

My understanding (perhaps out of date) is that some developers uses it for unknown purposes.

[Bill]

Ah so whereas the test in question, for no apparent reason, used to try make membership use a port range within the default membership port range (which also happened to lie in the ephemeral port range), with this PR the test has membership use ports from from the (non-ephemeral) port range specified by our test-running infrastructure.

[Bill]

Nice one @dhemery !

Approved ✓