Add support for image name substitution (prefixing of Docker Hub images)

[bohlenc]

Is your feature request related to a problem? Please describe.
To handle Docker Hub rate limiting, I want to use a pull through cache to proxy all images pulled from Docker Hub.
Currently, to make Testcontainers use this pull through cache, developers would have to modify the container setup for all images hosted on Docker Hub and prepend the hostname of the pull through cache to the image name. This is tiresome and error prone.

Describe the solution you'd like
I would like to centrally configure a prefix that is prepended to all image names hosted on Docker Hub.

Example: with a configured prefix "my.proxy.com" the image "docker:latest" becomes "my.proxy.com/docker:latest" and the image "my.azurecr.io/docker:latest" would be left as is.

Describe alternatives you've considered

• Manually changing all usages of Docker Hub images
• Implementing custom code on top of Testcontainers to centrally configure a prefix

Additional context
Testcontainers for Java already has a feature called Image Name Substitution (https://www.testcontainers.org/features/image_name_substitution/).

I already implemented support for a simple prefixing substitution strategy. If you agree with the premise of this issue, I can open a merge request.

[HofmeisterAn]

Yes — of course, we can add this functionality. But why do we need so many changes? Couldn't we add this functionality with just a few lines in DockerImage?

[bohlenc]

I think we could manage without the changes to TestcontainersBuilder and move the application of the substitution into DockerImage. I initially chose not to, because I see DockerImage as a simple primitive which I rather keep clean of any kind of logic or policy.
I introduced the abstraction of IImageNameSubstitution because I see the case for additional implementations, like testcontainers-java provides.

If you disagree here, I am certainly willing to simplify and move the functionality into DockerImage so we can get this merged.

[HofmeisterAn]

I'm just thinking about a simpler implementation. It looks so much code for such a simple task. Maybe it's better to extend the builder with a private method that append the prefix.

[bohlenc]

I just think the code is better structured and extensible the way it currently is. Besides, a significant portion of the added LoC is test data and documentation.
But I definitely understand your desire to keep the code base simple. And I agree with you - there is a simpler solution to precisely solve the task at hand, and not more.

To bring this to a fruitful end: I will get rid of the abstraction and add the core logic directly in TestcontainersBuilder next thing in the morning.

[bohlenc]

Done :).