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

Start in org.testcontainers.containers.GenericContainer#doStart and inspect logger(), DockerLoggerFactory, and getDockerImageName(). Reproduce the INFO-level startup with the inaccessible ECR image shown in the report; done means a disabled debug message does not resolve the image or raise an exception, allowing the fallback path to proceed.