feat: Update CosmosDb image to vnext-preview version

[NelsonBN]

What does this PR do?

This PR updates the CosmosDb image to the new version Microsoft is working on

Linux-based emulator (preview)
GitHub Repository

Why is it important?

This new image significantly improves the container startup process, eliminates certificate-related workarounds, and integrates seamlessly with CI/CD pipelines like GitHub Actions. For reference, you can check some of my tests here and GitActions here.

Related issues

#1306

Details

Explorer UI Disabled

The explorer UI was disabled since the container's purpose is to test integration with the Cosmos DB API.

return base.Init()
    .WithImage(CosmosDbImage)
    .WithEnvironment("ENABLE_EXPLORER", "false");

Internal Routing Configuration

For internal routing to work as expected, the API port and mapping port need to be configured with the same value. References.

.WithEnvironment("PORT", CosmosDbPort.ToString())
.WithPortBinding(CosmosDbPort, CosmosDbPort);

CosmosClient Configuration

The CosmosClient must be configured to use Gateway mode. See the official guidance.

public CosmosClient CosmosClient => new(GetConnectionString(), new() { ConnectionMode = ConnectionMode.Gateway });

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	53f35d8
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-dotnet/deploys/6776cfee4a8c1f00085cabdd
😎 Deploy Preview	https://deploy-preview-1324--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 creating the PR. Have you seen this discussion? I would like to wait until an official version is published. In addition, we do not use static ports. While GetAvailablePort() does not return a static port per se, it may fail for remote container runtimes (it does not resolve the mapped port from the container host).

For internal routing to work as expected, the API port and mapping port need to be configured with the same value. References.

According to the discussion, this is unnecessary, and it is why we used the DelegatingHandler in the past.

I think we can prepare a PR and merge it as soon as the official version is published, but I favor and would like to implement the proposed changes from the discussion.

[NelsonBN]

Thanks for creating the PR. Have you seen this discussion? I would like to wait until an official version is published. In addition, we do not use static ports. While GetAvailablePort() does not return a static port per se, it may fail for remote container runtimes (it does not resolve the mapped port from the container host).

For internal routing to work as expected, the API port and mapping port need to be configured with the same value. References.

According to the discussion, this is unnecessary, and it is why we used the DelegatingHandler in the past.

I think we can prepare a PR and merge it as soon as the official version is published, but I favor and would like to implement the proposed changes from the discussion.

@HofmeisterAn Thanks for your comment. I hadn't come across that discussion. I only checked if there were any open issues. I ended up commenting there in the discussion as well.

Looking at the discussion, it seems that using the rewriting of the DelegatingHandler is still the best approach, as it also removes the need to know in advance the port where the container will be randomly opened. Even so, some workarounds, like bypassing the certificate, are no longer necessary.