make TestGetHostPortRange unit test deterministic

[singholt]

Summary

make TestGetHostPortRange unit test deterministic

I noticed that the TestGetHostPortRange unit test relies on the underlying host's port availability. example failure

2023-02-22T08:49:37.6412749Z === RUN   TestGetHostPortRange/tcp_protocol,_contiguous_hostPortRange_found
2023-02-22T08:49:37.6412935Z     ephemeral_ports_test.go:144: 
2023-02-22T08:49:37.6413203Z         	Error Trace:	ephemeral_ports_test.go:144
2023-02-22T08:49:37.6413427Z         	Error:      	Not equal: 
2023-02-22T08:49:37.6413669Z         	            	expected: 40010
2023-02-22T08:49:37.6413896Z         	            	actual  : 40012
2023-02-22T08:49:37.6414282Z         	Test:       	

The getHostPortRange method does a net.Listen/net.ListenPacket calls on the host to check if a port is available. In the unit test, we check if the assigned ports matches an expected set of ports. This leads to it occasionally failing on PRs GH workflow, depending on whether a port is available at that point in time.

Implementation details

This PR refactors the getHostPortRange method and mocks the part where we do the port check on the host, in the unit test.

Testing

Existing unit tests succeed.

New tests cover the changes: no

Description for the changelog

make TestGetHostPortRange unit test deterministic

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Realmonia]

Looks good to me. Can you give an example around why sometimes the specific port is not available?

[singholt]

Looks good to me. Can you give an example around why sometimes the specific port is not available?

thanks for reviewing this PR! I am not sure how GH workflows run unit tests and what setup is shared across multiple runs. This PR is just based on observations from previous GH workflow unit test failures, like the one I linked in the description.

I suspect if multiple PRs run tests together, they may be running on the same host at the same time. This is just my guess. This PR doesn't change any existing functionality anyways, just mocks the runtime check which it should.

[Realmonia]

Looks good to me. Can you give an example around why sometimes the specific port is not available?

thanks for reviewing this PR! I am not sure how GH workflows run unit tests and what setup is shared across multiple runs. This PR is just based on observations from previous GH workflow unit test failures, like the one I linked in the description.

I suspect if multiple PRs run tests together, they may be running on the same host at the same time. This is just my guess. This PR doesn't change any existing functionality anyways, just mocks the runtime check which it should.

Sounds good