[fix][broker] Propagate bundle split failures to the completion future - #26735

Motivation

When using a non-extensible load manager, a failed bundle cache load can leave the future returned by NamespaceService.splitAndOwnBundle() pending indefinitely.

In splitAndOwnBundleOnceAndRetry(), the stage returned by splitBundles(...).thenAccept(...) is discarded. If splitBundles() completes exceptionally, the success callback is skipped and updateFuture is never completed. The outer completion future consequently remains pending.

The surrounding try/catch does not handle exceptional future completion, including when the returned future has already failed. The ownership-release timeout does not cover this failure because it is only installed after the namespace bundle update succeeds.

Modifications

• Handle exceptions on the stage returned by splitBundles(...).thenAccept(...) and propagate them to updateFuture, allowing the existing failure-handling path to complete the outer future.
• Add NamespaceServiceSplitFailureTest in the broker test group, covering both an already-failed policies read and a policies read that fails after splitAndOwnBundle() returns.
• Exercise the real namespace service and bundle factory with an isolated, non-started broker test context, injecting failures at the local policies read boundary.

Verifying this change

• Make sure that the change passes the CI checks.
  [fix][broker] Propagate bundle split failures to the completion future zhanghaou/pulsar#9

The new parameterized regression test asserts that the outer future completes exceptionally with ServiceUnitNotReadyException in both failure timings.

Local validation:

• Without the fix, both cases fail because the outer future remains pending.
• With the fix, both cases pass with the default test-group filters.
• quickCheck passes.

./gradlew :pulsar-broker:test \
  --tests 'org.apache.pulsar.broker.namespace.NamespaceServiceSplitFailureTest' \
  -PtestRetryCount=0 \
  -PtestFailFast=false

./gradlew quickCheck

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