[improve][broker] Change log level from warn to debug when cursor mark-deleted position ledger doesn't exist

[Shawyeok]

Motivation

Fixes #20408

It's possible that the ledger at the mark-deleted position is empty and has been deleted already. This is not an error condition, so it should be logged at debug level instead of warn level to reduce noise in production logs.

Verifying this change

• Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.

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: Shawyeok#25

[lhotari]

LGTM

[oneby-wang]

It's possible that the ledger at the mark-deleted position is empty and has been deleted already.

I'm wondering if the fix in this PR is reasonable: #25117. The goal is to keep the ledger data and the mark-deleted position consistent, thereby eliminating similar warning logs.

[Shawyeok]

I'm wondering if the fix in this PR is reasonable: #25117. The goal is to keep the ledger data and the mark-deleted position consistent, thereby eliminating similar warning logs.

@oneby-wang

IMO, we should only change the mark-deleted position of a cursor when there's an actual user acknowledgment. Here's why:

• If the mark-deleted position changes from 1000:-1 to 1100:-1 just to stay consistent with the managed ledger's ledger list, we lose visibility into whether any real acknowledgments occurred during that period. Keeping the mark-deleted position as-is preserves that information — we can tell that no messages were actually acknowledged.

• I don't see a clear benefit from enforcing this consistency. The managed ledger's ledger list is a ConcurrentSkipListMap, which handles lookups for the lowest bound greater than the mark-deleted position just fine.