[fix][broker] Observe replicated subscription update ack failures

[Denovo1998]

Motivation

When a replicated subscription update marker is received, the broker acknowledges the target subscription position asynchronously. The returned future was previously ignored, so failures from the ack path could be dropped without any logging or completion observation.

This makes replicated subscription state updates harder to diagnose when the local ack fails.

Modifications

• Add a helper to acknowledge replicated subscription updates and observe the returned future.
• Log replicated subscription update ack failures with the subscription name and position.
• Use the same helper for both existing subscriptions and subscriptions created from incoming replicated updates.
• Observe subscription creation failures in the create-subscription path.
• Add a regression test that verifies the update ack future is observed.

Verifying this change

• Make sure that the change passes the CI checks.

• gradlew :pulsar-broker:test --tests org.apache.pulsar.broker.service.persistent.ReplicatedSubscriptionsControllerTest -PtestRetryCount=0`

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

[void-ptr974]

Non-blocking: this branch is also changed by the PR, but the new test only covers the case where the subscription already exists. It would be useful to add a small test where topic.getSubscription(...) returns null, createSubscription(...) completes successfully, and the ack future returned by the newly-created subscription is observed. That would protect the create-then-ack path from regressing.

[Denovo1998]

Thanks for pointing this out. I added testReplicatedSubscriptionUpdateCreatedSubscriptionAckFutureIsObserved to cover the create-then-ack path: topic.getSubscription(...) returns null, createSubscription(...) completes with the newly-created subscription, and the ack future returned by that subscription is asserted to be observed.

[void-ptr974]

LGTM. This change observes the future returned by replicated subscription update acknowledgements, so async ack failures are no longer silently dropped. On failure it logs the subscription name, target position, unwrapped exception, and topic context from the controller logger.

The tests cover both update paths now: when the subscription already exists, and when the subscription is created from the incoming replicated update before applying the ack.