[fix][broker] Fix the retry mechanism in MetadataCache#readModifyUpdateOrCreate

[RobertIndie]

Motivation

The method MetadataCache#readModifyUpdateOrCreate should handle the BadVersionException by retrying the modification process, as already noted in the Java documentation: "The modify function can potentially be called multiple times due to concurrent updates."

Currently, MetadataCache#readModifyUpdateOrCreate does not catch the BadVersionException on the second attempt, allowing the exception to be passed to the caller. This issue can be easily reproduced by increasing concurrent futures in the test MetadataCacheTest#readModifyUpdateBadVersionRetry.

The current retry implementation is incorrect and lacks a backoff mechanism, which could lead to too many requests to the metadata store.

Modification

• Correct the retry process in MetadataCache#readModifyUpdateOrCreate to ensure BadVersionException is caught during each retry.
• Implement a retry backoff mechanism in MetadataCache#readModifyUpdateOrCreate to manage the frequency of retries effectively.
• Add new config retryBackoff to the MetadataCacheConfig to control the MetadataCache retry backoff.
• Respective the metadataStoreOperationTimeoutSeconds for the MetadataCache retry

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

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

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.33%. Comparing base (bbc6224) to head (3219d51).
Report is 1207 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #23686      +/-   ##
============================================
+ Coverage     73.57%   74.33%   +0.76%     
- Complexity    32624    35071    +2447     
============================================
  Files          1877     1945      +68     
  Lines        139502   147505    +8003     
  Branches      15299    16280     +981     
============================================
+ Hits         102638   109649    +7011     
- Misses        28908    29375     +467     
- Partials       7956     8481     +525     

Flag	Coverage Δ
inttests	27.33% <74.19%> (+2.75%)	⬆️
systests	24.33% <74.19%> (+0.01%)	⬆️
unittests	73.72% <100.00%> (+0.87%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
.../apache/pulsar/broker/resources/BaseResources.java	75.65% <100.00%> (+2.92%)	⬆️
...in/java/org/apache/pulsar/common/util/Backoff.java	94.11% <ø> (ø)
...pache/pulsar/metadata/api/MetadataCacheConfig.java	90.90% <100.00%> (+10.90%)	⬆️
.../pulsar/metadata/cache/impl/MetadataCacheImpl.java	86.89% <100.00%> (-2.36%)	⬇️
...he/pulsar/metadata/impl/AbstractMetadataStore.java	84.94% <100.00%> (+0.38%)	⬆️

... and 663 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dao-jun]

LGTM