[Enhancement]: Debug Messages should be calling arguments, when debug level is disabled

Module

MySQL

Proposal

I face the issue with MySQL, but I suppose that can be the case for other libs as well.
My case.
I create a custom MySQL image, which is stored on ECR.
I start it like

	private static CustomMysqlContainer createInstance() {
		String imageName = determineImageName(); // image name is from ECR
		try {
			log.info("Initializing CustomMysqlContainer with image: {}", imageName);
			CustomMysqlContainer instance = new CustomMysqlContainer(imageName);
			instance.withStartupAttempts(1).start();
			return instance;
		} catch (Exception e) {
			log.error("Failed to initialize CustomMysqlContainer with custom image: {}. Falling back to generic image.", imageName, e);
			return fallbackInstance(); // here standard image is created
		}
	}

So my expectation is that when a single attempt fails, the fallback is used.
What I see is that exception is thrown when debug message is going to be printed, in the class
org.testcontainers.containers.GenericContainer#doStart

    protected void doStart() {
        try {
            if (this.waitStrategy != DEFAULT_WAIT_STRATEGY) {
                this.containerDef.setWaitStrategy(this.waitStrategy);
            }

            configure();

            logger().debug("Starting container: {}", getDockerImageName()); // <-- here the error is happening

and process is locked in some kind of internal loop, which I can't fully understand
Exception trace:

2025-01-22T18:05:50.8718829Z Caused by: org.testcontainers.shaded.org.awaitility.core.ConditionTimeoutException: Condition org.testcontainers.images.RemoteDockerImage$$Lambda/0x00007f764c7052d8 was not fulfilled within 2 minutes.
2025-01-22T18:05:50.8719663Z 	at org.testcontainers.shaded.org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
2025-01-22T18:05:50.8720225Z 	at org.testcontainers.shaded.org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
2025-01-22T18:05:50.8720916Z 	at org.testcontainers.shaded.org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
2025-01-22T18:05:50.8721625Z 	at org.testcontainers.shaded.org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
2025-01-22T18:05:50.8722174Z 	at org.testcontainers.shaded.org.awaitility.core.ConditionFactory.until(ConditionFactory.java:954)
2025-01-22T18:05:50.8722678Z 	at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:105)
2025-01-22T18:05:50.8723255Z 	at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:33)
2025-01-22T18:05:50.8723715Z 	at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:20)
2025-01-22T18:05:50.8724119Z 	at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:41)
2025-01-22T18:05:50.8724576Z 	at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1362)
2025-01-22T18:05:50.8724977Z 	... 68 common frames omitted

My logging level is INFO

Testcontainers version: 1.19.8
My expectation: No errors is caused by debug messages.

It looks like logger factory is based on the docker image name, which throws exception in my case when no credentials is configured for ECR

    protected Logger logger() {
        return DockerLoggerFactory.getLogger(this.getDockerImageName());
    }

org.testcontainers.containers.GenericContainer#doStart から始めて、logger()、DockerLoggerFactory、getDockerImageName() を調べます。レポートに示されているアクセスできない ECR イメージを使って INFO レベルの起動を再現します。無効化されたデバッグメッセージがイメージを解決せず、例外も発生させないため、フォールバックパスを続行できれば完了です。