Allow to disable configuration of EnvironmentAndSystemPropertyClientProviderStrategy through Testcontainers

[kiview]

#4118 added the ability to configure EnvironmentAndSystemPropertyClientProviderStrategy through the Testcontainers configuration mechanism. However, in some advanced use cases, it can be desirable to keep the legacy behavior for configuring Docker host detection only.

This PR allows switching this behavior by configuring dockerconfig.source as either testcontainers (current behavior) or docker (legacy behavior).

In addition, EnvironmentAndSystemPropertyClientProviderStrategy is not considered a persistable strategy anymore. In most cases, this should effectively make no difference since it is the strategy with the highest priority of the strategies that are included in Testcontainers.

This high priority strategy property is also the reason, why this PR removes the code introduced by #4175, since it still will be selected by the discovery mechanism.

[kiview]

Once the new docker-java version is released, we can change the ENV check to the new getter from docker-java/docker-java#1692.

[rnorth]

Shouldn't we add some unit tests for this? Our configuration/environment detection is pretty complex and regressions are especially painful to detect.

[kiview]

I was only thinking about TestcontainersConfigurationTest, which would not have captured this change, but we can add a test to EnvironmentAndSystemPropertyClientProviderStrategyTest (using Mocks), that makes sense 👍

[kiview]

@rnorth I added unit tests, that captures the behavior. But TBH, I am not sure if this will save us from regressions since they are extremely whitebox and IMO the regressions are most likely to be introduced through a combination of EnvironmentAndSystemPropertyClientProviderStrategy, TestcontainersConfiguration and DockerClientProviderStrategy in combination with the environment. This is also reflected by the fact that this unit test (with this corresponding implementation) was an overspecification that was already effectively enforced through the interaction of those components.

Another indicator for this test is too tightly connected to the implementation come from the fact, that we have to change the test (i.e. the mocking) once we switch to using the new getter in docker-java.

[bsideup]

👍

[bsideup]

@kiview the code looks good. There are some CI failures tho - PTAL

[kiview]

With ❤️ from the Gradle Plugins server 🙄