[fix][broker] Prevent early replay of non-strict delayed messages

[coderzc]

Motivation

InMemoryDelayedDeliveryTracker rounds non-strict delivery timestamps down to reduce the number of timestamp keys. Availability checks currently compare that bucket start directly with the non-strict cutoff (now + tickTimeMillis).

The original deliverAt can be up to precisionMillis - 1 later than the bucket start. As a result, the tracker can expose a position before the original timestamp is inside the configured early-delivery window. The dispatcher then reads the entry, addMessage checks the original deliverAt, and inserts the same position back into an already eligible bucket. An active dispatcher can repeat this replay until the original timestamp reaches the cutoff, causing unnecessary reads.

With the default 1000 ms tick and 512 ms timestamp buckets, this inconsistent window can be up to 511 ms.

Regression source and related changes

• #23611 changed the in-memory tracker from a per-message priority queue to timestamp buckets and trimmed the lower timestamp bits. This is the change that introduced the timestamp-down-rounding behavior involved in this issue.
• #26012 fixed the analogous early-bucket problem for strict delivery by changing strict-mode cutoff handling. This PR complements that fix for non-strict mode, where the configured early-delivery window must remain unchanged.

Modifications

• Adjust the non-strict bucket cutoff by the maximum timestamp rounding distance, so a bucket is exposed only when its upper bound is inside the configured early-delivery window.
• Keep the existing timestamp representation, strict-mode behavior, timer state machine, and configuration semantics unchanged.
• Add a deterministic regression test that runs repeated dispatch rounds at a fixed clock time and counts replay reads of the same position.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• ./gradlew :pulsar-broker:test --tests 'org.apache.pulsar.broker.delayed.InMemoryDeliveryTrackerTest' -PtestRetryCount=0
• ./gradlew quickCheck

The new regression test was also verified against the unpatched implementation: the same position was replayed and re-added 10 times while the clock remained fixed. With the fix it is replayed zero times before the early-delivery window, then exactly once after the full bucket enters that window.

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

[lhotari]

#23611 was reverted from 4.0.x by #24429 so there's no need for fixing this in branch-4.0.