Remove withPublishAllPorts from Ryuk and stabilize containerInfo content on start

[kiview]

Changes the start behavior of GenericContainer to ensure, that containerInfo is populated with all mapped ports.
In addition, withPublishAllPorts is removed from Ryuk, since the method is deprecated and can lead to non-usable ports on Docker for Windows.

This PR contains quite duplicate code with regards to polling containerInfo until the response stabilizes. I was not sure where to best extract this code to. Therefore, I submitted the PR in order to discuss this as well.

This PR should improve Windows stability substantially and fix the issues described in #3609, originating upstream from docker/for-win#3171.
In addition, the non-idempotent behavior of InspectContainerCmd, as also observed in testcontainers/testcontainers-go#294 is handled, as it was also done in testcontainers/testcontainers-go#295.

I have further created an issue upstream at docker/for-win#11584.

[kiview]

Not sure why HttpWaitStrategyTest on CI would fail:
https://github.com/testcontainers/testcontainers-java/runs/2971856438#step:6:1753

Works fine locally.

[rnorth]

Should we include a small sleep to give the API results time to update?

[kiview]

Oh, I thought sleeping is built into Unreliables, it is not? Then I probably confused this with Awaitility. 100ms?

[kiview]

Interestingly, the last commit made ReusabilityUnitTests fail. I have a feeling, that the test has some wrong assumptions with regards to the immutability of the docker inspect statement response. Not sure why implementing the suggestion by @rnorth made the test fail.

[bsideup]

@kiview ReusabilityUnitTests makes use of mocks, so please double check that there isn't something like "expected 1 call but received 3" :)

[kiview]

Oh, I lost the context over the weekend. I added the if-clause specifically for the ReusabilityUnitTests, since the return value of InspectContainerResponse.getNetworkSettings() will be null. But of course, it was not that ideal to change production code only to make the test work again (unless there might be a situation, where getNetworkSettings() can be null for a valid reason and the container should nevertheless proceed in starting.

Is there an alternative to creating an InspectContainerResponse with all required data, except deep stubbing or reflection?

[bsideup]

As discussed on Slack, we should handle withCreateContainerCmdModifier-like case, where additional ports are exposed without an entry in exposedPorts

[kiview]

In addition, containers from images that have ports defined using EXPOSE, will also report those in the API resonse.

[bsideup]

@kiview even without PublishAll? o_O

[kiview]

Yes, because they are still exposed, just not published. I added those cases into a test, to increase the chance of failure in case of a regression on our side.