[fix][test] Fix flaky RateLimiterTest.testDispatchRate

[lhotari]

Motivation

RateLimiterTest.testDispatchRate is flaky in CI. Recent example: PR #25844 run 26175306430 job 77005756965.

Gradle suite > Gradle test > org.apache.pulsar.common.util.RateLimiterTest > testDispatchRate FAILED
    java.lang.AssertionError: expected [true] but found [false]
        at org.apache.pulsar.common.util.RateLimiterTest.testDispatchRate(RateLimiterTest.java:210)

The test invokes tryAcquire(100) three times on a dispatch-rate RateLimiter (which has no upper bound on acquiredPermits, only back-pressure), leaving acquiredPermits = 300. It then sleeps 3 * rateTimeMSec (3 s) and asserts getAvailablePermits() > 0, expecting the scheduled renew task to have run three times and subtracted 3 * permits from acquiredPermits.

The renew is scheduled via ScheduledExecutorService.scheduleAtFixedRate(...) at a 1 s rate. Under CI load, the third tick can fire slightly after the assertion runs, so acquiredPermits is still ≥ 100 and getAvailablePermits() is still 0, failing the assertion.

Modifications

Replace the fixed Thread.sleep(rateTimeMSec) + assertion with Awaitility.await().atMost(10 * rateTimeMSec, MILLISECONDS).until(() -> rate.getAvailablePermits() > 0). This polls for the expected post-condition instead of relying on the scheduler firing on a fixed wall-clock budget. Also drops the intermediate assertEquals(getAvailablePermits(), 0) check after 2 s, since it is the same kind of timing-sensitive snapshot.

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as the modified testDispatchRate itself, plus the other timing tests in RateLimiterTest.