Make container names unique and migrate all tests to singletons

[gnodet]

Summary

This PR makes test infrastructure safe for both cross-JVM (mvnd parallel builds) and within-JVM (parallel test classes) execution by ensuring Docker container name uniqueness and migrating tests to share singleton service instances.

Commit 1: Make Docker container names unique per instance

• Append PID + AtomicInteger counter to container names in ContainerEnvironmentUtil.containerName() for cross-JVM and within-JVM uniqueness
• Remove hardcoded container name "nameserver" from RocketMQNameserverContainer (the network alias is sufficient for inter-container communication)

Commit 2: Add createSingletonService() to 32 test-infra service factories

• Add singleton factory methods following the established KafkaServiceFactory pattern (inner singleton class, lazy holder, factory method) to 32 service factories that previously only had createService()
• Change SingletonService.shutdown() from throwing IllegalArgumentException to a debug-level no-op, since many service interfaces have afterEach lifecycle callbacks that call shutdown() (e.g., ChatScriptService, CliService)

Commit 3: Migrate all test classes from createService() to createSingletonService()

• Migrate ~69 test files from createService() to createSingletonService() to share Docker containers across test classes
• Fix test isolation for shared services:
  • Hashicorp Vault: Use getClass().getSimpleName() for unique secret paths per test class
  • Google PubSub: Use unique topic/subscription names per test class
• Keep createService() for tests that need exclusive instances:
  • BaseExclusiveKafkaTestSupport (intentionally needs isolation)
  • KafkaHealthCheckTestSupport (tests intentionally shut down Kafka to verify health check DOWN behavior)
  • AbstractLRATestSupport (LRA coordinator state leaks between test classes)
  • MasterEndpointFailoverIT (manages its own ZooKeeper lifecycle)

Test plan

• CI passes on JDK 17, 21, 25
• No container name collisions with parallel execution
• Singleton services create exactly one container per JVM
• Tests that shut down services (health checks, LRA) use non-singleton instances

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[orpiske]

LGTM, but this one likely needs a full CI test to make sure it runs fine.

[gnodet]

LGTM, but this one likely needs a full CI test to make sure it runs fine.

Yes, I'm running tests locally for each modified factory to make sure it works.
The one that don't work will have a comment:
https://github.com/apache/camel/pull/22294/changes#diff-4677c71b137d3f514242cb2407edc44042f5f8068594d75177c07522fb0de878R48

It's not completely done yet...