[merlimat]

Motivation

DelayMessagingTest.delayMsgBlockTest is the slowest method of CI - Integration - Messaging: 60-62 s in the
scheduled master runs of 3 Nov, almost all of it fixed delays. It is #10078's regression test for delayed messages
that the broker stopped dispatching after many retries, and it reconsumes its message 11 times with
reconsumeLater(5, SECONDS): 55 s.

A shorter delay still goes through the broker's delayed delivery tracker, as long as it is longer than the tracker's
tick (delayedDeliveryTickTimeMillis, 1 s). With isDelayedDeliveryDeliverAtTimeStrict=false, the default, the
tracker dispatches a message that is due within a tick at once, without tracking it:

public boolean addMessage(long ledgerId, long entryId, long deliverAt) {
    if (deliverAt < 0 || deliverAt <= getCutoffTime()) {   // clock.millis() + tickTimeMillis
        messagesHaveFixedDelay = false;
        return false;
    }

DelayMessagingTest and TestScalableTopicMigration (20-22 s) also create their namespace and partitioned topic with
pulsar-admin, a JVM start in a broker container each (~1.5 s locally, ~4 s on CI).

Modifications

Test code only.

• DelayMessagingTest: the delay is 2 s. Each receive still waits up to 10 s, as it did (twice the 5 s delay):
  a tracked message arrives within a tick of its delivery time, and one that the broker stops dispatching never does.
• DelayMessagingTest and TestScalableTopicMigration create their namespace and partitioned topic with the admin
  client. The commands that TestScalableTopicMigration tests, scalable-topics migrate and get-metadata, still
  run through pulsar-admin.

Verifying this change

• Make sure that the change passes the CI checks.

This change is covered by the tests it changes.

Local times, on a 10-CPU Docker VM with an image built from apache/master:

Method	master	this PR
DelayMessagingTest.delayMsgBlockTest	57.9 s	22.4 s
TestScalableTopicMigration.testMigrateRegularTopicToScalable	9.9 s	6.4 s

On CI, ~35 s and ~8 s less.

The test still catches delayed messages that stop being dispatched. On a broker image whose
AbstractDelayedDeliveryTracker.run(Timeout) returns at once, so that the tracker's timer never triggers a read of
the messages that are due (patched into the image, not committed):

• master's test fails: Consumer can't receive message in double delayTimeSeconds time 10s;
• this PR's test fails the same way: Consumer can't receive message in 10s;
• with a 1 s delay, the test passes in 2.1 s, since its messages never reach the tracker: hence 2 s.

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