[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());
    }

Commencez dans org.testcontainers.containers.GenericContainer#doStart et inspectez logger(), DockerLoggerFactory et getDockerImageName(). Reproduisez le démarrage au niveau INFO avec l’image ECR inaccessible présentée dans le rapport ; c’est terminé lorsqu’un message de débogage désactivé ne résout pas l’image et ne déclenche pas d’exception, ce qui permet à la voie de repli de continuer.