[improve][offload]PIP-211: Introduce Offload throttling, P1

[dao-jun]

PIP: #18004

Motivation

See #18004

Modifications

1. Move AsyncTokenBucket related classes from pulsar-broker to pulsar-common
2. Add OffloadLedgerHandle.java
3. Pass OffloadLedgerHandle's instance to LedgerOffloader instead of LedgerHandle.

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:

[dao-jun]

Origin PR: #17485

[lhotari]

I think that AsyncTokenBucket should be used for rate limiting instead of implementing a separate solution. It was introduced in PIP-322.

[dao-jun]

I think that AsyncTokenBucket should be used for rate limiting instead of implementing a separate solution. It was introduced in PIP-322.

@lhotari
TimeWindow is not introduced by this PR, it exists a long time. Just reuse it here. If you think AsyncTokenBucket is better, I can fix this.

[dao-jun]

@lhotari I will move AsyncTokenBucket related class from pulsar-broker to pulsar-common, is it OK?

[lhotari]

I think that AsyncTokenBucket should be used for rate limiting instead of implementing a separate solution. It was introduced in PIP-322.

@lhotari
TimeWindow is not introduced by this PR, it exists a long time. Just reuse it here. If you think AsyncTokenBucket is better, I can fix this.

Yes, I think so. It's worth checking if you could implemented the rate limiting in a similar way as it is in other Pulsar rate limiters that were refactored in PIP-322 implementation.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 83.05085% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 73.71%. Comparing base (bbc6224) to head (ada5b82).
Report is 107 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #22385      +/-   ##
============================================
+ Coverage     73.57%   73.71%   +0.13%     
+ Complexity    32624    32404     -220     
============================================
  Files          1877     1886       +9     
  Lines        139502   139926     +424     
  Branches      15299    15326      +27     
============================================
+ Hits         102638   103141     +503     
+ Misses        28908    28810      -98     
- Partials       7956     7975      +19     

Flag	Coverage Δ
inttests	27.03% <11.86%> (+2.45%)	⬆️
systests	24.48% <52.54%> (+0.16%)	⬆️
unittests	72.98% <79.66%> (+0.14%)	⬆️

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

Files	Coverage Δ
...apache/bookkeeper/mledger/ManagedLedgerConfig.java	96.38% <100.00%> (+0.08%)	⬆️
...che/bookkeeper/mledger/impl/ManagedLedgerImpl.java	80.95% <100.00%> (+0.29%)	⬆️
...org/apache/pulsar/broker/ServiceConfiguration.java	99.39% <100.00%> (+<0.01%)	⬆️
...n/java/org/apache/pulsar/broker/PulsarService.java	82.62% <ø> (+0.25%)	⬆️
...ker/resourcegroup/ResourceGroupPublishLimiter.java	86.95% <ø> (ø)
...rg/apache/pulsar/broker/service/BrokerService.java	80.96% <100.00%> (+0.18%)	⬆️
.../pulsar/broker/service/PublishRateLimiterImpl.java	86.15% <ø> (ø)
...broker/service/persistent/DispatchRateLimiter.java	78.63% <ø> (ø)
...roker/service/persistent/SubscribeRateLimiter.java	54.54% <ø> (ø)
...ava/org/apache/pulsar/broker/stats/TimeWindow.java	66.66% <ø> (ø)
... and 8 more

... and 181 files with indirect coverage changes