[Bug]: EventHub configuration produce errors

[scrocquesel-ml150]

Testcontainers version

4.4.0

Using the latest Testcontainers version?

Yes

Host OS

Linux

Host arch

x86

.NET version

8

Docker version

N/A

Docker info

N/A

What happened?

var configuration = EventHubsServiceConfiguration
            .Create()
            .WithEntity("test", 2, [Azure.Messaging.EventHubs.Consumer.EventHubConsumerClient.DefaultConsumerGroupName]);

        var builder = new EventHubsBuilder()
            .WithAcceptLicenseAgreement(true)
            .WithConfigurationBuilder(configuration);

        _eventHubsContainer = builder.Build();

        await _eventHubsContainer.StartAsync();

1. The default namespace name produce a "Recoverable validation failed" logs but this does not fail. We should change the default name to the valid one "emulatorns1".
2. The emulator create a "$default" group and do not allow to specify it in the config. But the configuration validate that we must pass at least one consumer group which is not necessary if we use the default one.
3. When the container stop due to a a bad configuration, testcontainer still wait for it to be ready.

Relevant log output

warn: HostHelper[0]
      Recoverable validation failed on user config:Expected string to be "emulatorns1" with a length of 11 because NamespaceName is non-modifiable.Only supported emulatorns1, but "ns-1" has a length of 4, differs near "ns-" (index 0).
Unhandled exception. FluentAssertions.Execution.AssertionFailedException: Expected string not to be equivalent to "$default" because Consumer group $default is internally created., but they are.

Additional information

I can push a PR for the first two points.
Some guidance on how should the wait strategy be modified so it detect the container has stopped is welcome.

[HofmeisterAn]

Thanks for creating the issue. I'm not quite sure if I understood it. Are you saying that if the entity name is set to $Default, the startup fails because our namespace uses ns-1 instead of emulatorns1?

A contribution would be welcome, maybe then I understand the issue better.

Regarding 3., are you referring to the wait strategy never failing and just running forever? That's a general issue we have and should probably address in a separate PR. Some wait strategies can at least fail if the container exits (not all of them do).