[improve][broker] Centralize mark-delete position change handling

[nodece]

Motivation

Dispatcher notification logic (afterAckMessages + markDeletePositionMoveForward) was scattered across multiple callback sites in PersistentSubscription (markDeleteCallback, deleteCallback, clearBacklog, skipMessages, resetCursor). This led to:

• Duplicated dispatcher.afterAckMessages() calls that could fire even when the mark-delete position hadn't actually changed.
• Redelivery tracker and pending acks cleanup was only performed inside readMoreEntries() for the PersistentDispatcherMultipleConsumers base class, meaning Key_Shared subscriptions had to duplicate the logic. Other subscription types (Shared, Failover) missed cleanup opportunities when messages expired via TTL.
• PersistentMessageExpiryMonitor only triggered markDeletePositionMoveForward() for Key_Shared subscriptions, leaving other subscription types without proper cleanup after message expiry.

Changes

• PersistentSubscription

  • Consolidated all dispatcher.afterAckMessages() calls into the single notifyTheMarkDeletePositionChanged() method, which now also calls dispatcher.markDeletePositionMoveForward().
  • Removed scattered afterAckMessages calls from markDeleteCallback, deleteCallback, clearBacklog, skipMessages, and resetCursor.
  • Added oldMarkDeletePosition capture in clearBacklog, skipMessages, and resetCursor to route through the centralized path.

• PersistentDispatcherMultipleConsumers

  • Moved redelivery tracker and pending acks cleanup from readMoreEntries() into markDeletePositionMoveForward(), so it fires precisely when the mark-delete position advances rather than opportunistically on the next read cycle.
  • Removed lastMarkDeletePositionBeforeReadMoreEntries field.

• PersistentStickyKeyDispatcherMultipleConsumers

  • Added super.markDeletePositionMoveForward() call so Key_Shared subscriptions also clean up stale entries from the redelivery tracker and pending acks.

• PersistentMessageExpiryMonitor

  • Changed the post-expiry dispatcher notification from a Key_Shared-only check to a general dispatcher != null check, so all subscription types benefit from cleanup after message TTL expiry.

[lhotari]

Is there a significant different in the frequency that this gets called? When this logic was previously in readMoreEntries, it would only get called there if the mark delete position moved since the last call to readMoreEntries, which is not as frequent as the mark delete position might move forward. This has been intentional behavior in the past and I have a concern that this change would cause a performance regression.

[nodece]

There's likely a performance impact due to the higher invocation frequency. Thanks for pointing that out. I'll revisit the change and adjust it to avoid unnecessary executions!

[nodece]

Closed by #25592