[fix][test] Reduce admin client churn in ExtensibleLoadManagerTest.startBroker

[merlimat]

Motivation

ExtensibleLoadManagerTest.startBroker is a @BeforeMethod that runs before each test method (e.g. testStopBroker, testIsolationPolicy) to make sure all brokers are running and ready. Some test methods intentionally stop brokers, so the next method's startBroker waits for those brokers to come back.

The readiness check polled by creating a brand new PulsarAdmin per broker on every poll iteration:

for (BrokerContainer brokerContainer : pulsarCluster.getBrokers()) {
    try (PulsarAdmin brokerAdmin = PulsarAdmin.builder()
            .serviceHttpUrl(brokerContainer.getHttpServiceUrl()).build()) {
        ...
    }
}

That's 3 brokers × N polls of admin builder/close, each one establishing a new HTTP client. The connection setup work piles up against brokers that are still warming up after a stop/restart and the await can exhaust its 180s budget.

Example failure: https://scans.gradle.com/s/4dgsnjrtxayqa/tests/task/:tests:integration:integrationTest/details/org.apache.pulsar.tests.integration.loadbalance.ExtensibleLoadManagerTest/startBroker?top-execution=1

Modifications

Build the per-broker PulsarAdmin clients once before the await loop and reuse them across all poll iterations. Close them in a finally block. The readiness checks themselves (getActiveBrokers, createPartitionedTopic, lookupPartitionedTopic) are unchanged.

Verifying this change

This change is already covered by the existing ExtensibleLoadManagerTest integration test (which runs startBroker between every test method).

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment