Retry internal port checking in the same exec

[bsideup]

Exec'ing with Docker is slow. Even if the command itself takes 10ms to execute, docker exec would take 300ms or so. This PR adds while true-style waiting in the same exec session, so that we pay the overhead of exec only once.

Before:

Container confluentinc/cp-kafka:5.4.3 started in PT5.492S

After:

Container confluentinc/cp-kafka:5.4.3 started in PT4.387S

[bsideup]

minus dependencies on cat and awk, just in case :)

[kiview]

LGTM
Only thing I wondered if it makes any sense to still wrap it in Unreliables here:

testcontainers-java/core/src/main/java/org/testcontainers/containers/wait/strategy/HostPortWaitStrategy.java

Lines 44 to 45 in 672cbee

	Unreliables.retryUntilTrue((int) startupTimeout.getSeconds(), TimeUnit.SECONDS,
	() -> getRateLimiter().getWhenReady(() -> internalCheck.call() && externalCheck.call()));

Wouldn't this mean that a failing external check would still lead to unnecessary exec calls?

At least it does not hurt for now and keeps the PR small.

[bsideup]

@kiview one additional benefit of still having Unreliables there is to timeout (which will lead to container startup failure and the container being removed, so exec will eventually be terminated)

[kiview]

Makes total sense.
But maybe splitting () -> internalCheck.call() && externalCheck.call() into a sequence of two distinct Unreliables calls is still beneficial? As per my argument above, no need to re-evaluate internalCheck while waiting for externalCheck to become ready (my assumption).

Let me just try with Kafka, to see if there is an observable difference.

[bsideup]

@kiview I thought about it (and already have a prepared follow up for caching the results) 👍 Will do right after this one :)

[kiview]

Cool, just FYI, my naive experiment of

Unreliables.retryUntilTrue((int) startupTimeout.getSeconds(), TimeUnit.SECONDS,
    () -> getRateLimiter().getWhenReady(internalCheck));

Unreliables.retryUntilTrue((int) startupTimeout.getSeconds(), TimeUnit.SECONDS,
    () -> getRateLimiter().getWhenReady(externalCheck));

made in 1s slower 😱

[rnorth]

Oh this is fun; on Mac/Win the external check will possibly pass before the internal check (because of the userland proxy racing the real process). On Linux, if one passes the other really should be a no-op.

This gets weird to reason about if internalCheck is now blocking and externalCheck is polled.

I've deleted my thinking, but wrote more about this. TLDR is that I think we could overthink this, so let's just be guided by the numbers of what works quickly and what's easy to read 😂

[bsideup]

@rnorth yep, exactly the reason why we perform both :D The hidden gems of Testcontainers :D