feat: Refactor IImage properties to align with DSL

[jacobjmarks]

What does this PR do?

• Modifies IImage properties to align with DSL
  • Adds string Registry
  • Removes string Name
• Modifies DockerImage constructor to align with new properties
• Modifies MatchImage.Match(string) method to appropriately extract new properties
  • I used regex to do so. While the "requirements" shouldn't change, I'm happy to refactor to something a little more maintainable.

Why is it important?

Aligns terminology used with that of the general Docker/container DSL.

Related issues

• Resolves [Enhancement]: Refactor the IImage properties (align with DSL) #740

Follow-ups

• Does this new support for registries make the hubImageNamePrefix parameter obsolete?

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	40f14ad
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-dotnet/deploys/64c4bdd3f380ce00089d256a
😎 Deploy Preview	https://deploy-preview-962--testcontainers-dotnet.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[HofmeisterAn]

Thanks for the PR once again 😃. I have not had a chance to thoroughly review it yet, but I would like to give some quick feedback on something I noticed.

I believe we should try to introduce as few breaking changes as possible to ensure a smooth transition. For the replaced members, I suggest using the obsolete flag (although I do not think a lot of developers are using them). Also, I want to mention that I forgot to include the GetHostname() in the issue, but have updated it.

• Does this new support for registries make the hubImageNamePrefix parameter obsolete?

No, it does not. Developers have the option to configure it using the custom configurations to replace the default registry (host) from which they want to pull the images.

[jacobjmarks]

In this case, should the hubImageNamePrefix simply be considered the registry? I assume it will take precedence over any registry defined in the repository argument?

How do you want to handle the DockerImage constructor? I would look to do something like the following however it will clash with existing DockerImage(string, string, string) references.

// current constructor
[Obsolete]
public DockerImage(string repository, string name, string tag, string hubImageNamePrefix = null)
    : this(hubImageNamePrefix, $"{repository}/{name}", tag) { } // <-- forward to new constructor

// new constructor
public DockerImage(string registry, string repository, string tag) { }

[HofmeisterAn]

Sorry for the late response, I was not able to reply earlier.

In this case, should the hubImageNamePrefix simply be considered the registry? I assume it will take precedence over any registry defined in the repository argument? Like we are doing in GetHostname().

Yes, I think that make sense. Do you think we can remove the registry in case the repository argument (obsolete constructor) contains one? This will probably support most backwards compatibility.

How do you want to handle the DockerImage constructor? I would look to do something like the following however it will clash with existing DockerImage(string, string, string) references.

I have thought about that too. I do not think we can avoid a "breaking change", but I think the impact is very small.

• Not many developers will use this constructor.
• Internally, we use only the full name. I do not expect any issues 😬 (besides some existing tests).
• The old properties will still be available and marked as obsolete.