[fix][meta] Fix PulsarZooKeeperClient async addWatch callback retry behavior

[oneby-wang]

Motivation

The async ZooKeeper addWatch wrapper in PulsarZooKeeperClient defined a retry callback but delegated the operation using the original callback and context. If addWatch returned a recoverable error, the caller could observe the transient failure directly instead of retrying. The wrapper's completion branch also recursively invoked itself, which would be incorrect if the wrapper callback were used.

This affects the SessionReestablished path in ZKMetadataStore, where Pulsar recreates the persistent recursive watch before notifying session listeners.

Modifications

• Route async addWatch calls through the retry wrapper callback and ZooWorker context.
• Complete the caller-provided callback with the final result after retry handling.
• Fix the addWatch retry operation description.
• Add a regression test that verifies a recoverable CONNECTIONLOSS is retried and the caller receives the final OK result.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• Added MetadataStoreTest.testAsyncAddWatchRetriesWithWrapperCallback to cover addWatch retry callback behavior.

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