[fix][broker] Avoid blocking the bundle-throughput lookup on per-bundle metadata reads - #26054

Motivation

ModularLoadManagerImpl.getBundleDataOrDefault(String) reads bundle data (with a resource-quota fallback) from the metadata store, blocking on two .join() calls behind a plain BundleData return. Its clean signature hid that it blocks.

NamespaceBundleFactory.getBundleWithHighestThroughputAsync() called it once per bundle inside a getBundlesAsync(...).thenApply(...) continuation — so the continuation thread (which completes getBundlesAsync, a metadata-cache callback) blocked on a metadata read for every bundle in the namespace. This is reachable from the admin path (NamespacesBase.findHotBundleAsync).

Modifications

• Add ModularLoadManager.getBundleDataOrDefaultAsync(String), composing the two metadata reads asynchronously and returning the default BundleData on miss/error (preserving the exact logic of the blocking method). To stay backward compatible for custom ModularLoadManager implementations, it is a default method delegating to the existing sync method; ModularLoadManagerImpl overrides it with the real async implementation.
• Deprecate the blocking getBundleDataOrDefault(String); it now delegates to getBundleDataOrDefaultAsync(...).join(). All internal callers (the load-data update loop, preallocateBundle, selectBroker) and the tests now use the async variant, so the deprecated method has no remaining callers except the interface's compat bridge.
• NamespaceBundleFactory.getBundleWithHighestThroughputAsync() now composes getBundleDataOrDefaultAsync() for all bundles (thenCompose + waitForAll) and selects the max-throughput bundle off the already-complete futures — no blocking on the continuation thread.

Verifying this change

This change is covered by existing tests, which pass: ModularLoadManagerImplTest.testBundleDataDefaultValue and NamespaceServiceTest.testSplitBundleWithHighestThroughput.

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

If the box was checked, please highlight the changes

• 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