ingest/ledgerbackend: fix to ensure that the ledger buffer properly queues the last batch of ledgers (LCM) within the specified range

[urvisavla]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've reviewed the changes in this PR and if I consider them worthwhile for being mentioned on release notes then I have updated the relevant CHANGELOG.md within the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

The fix updates the boundary check in bounded mode to ensure the BufferedStorageBackend/LedgerBuffer queues ledgers up to the end boundary ledger of the specified range. This fixes an issue where the final batch of ledgers is skipped in scenarios where multiple ledgers are stored per file and the from ledger does not align with the start boundary of the stored file.

Why

This issue occurs only in bounded mode where multiple ledgers are stored per file.

For example:
Whenledgers_per_file is set to 4, each file contains 4 consecutive ledgers, resulting in files like:
0–3.xdr, 4–7.xdr, 8–11.xdr, 12–15.xdr, 16–19.xdr and so on.

Suppose we need to fetch ledgers 6 to 17 using the BufferedStorageBackend, so the from ledger is 6 and to ledger as 17:

1. The LedgerBuffer starts by downloading the file containing ledger 6 (4–7.xdr).
2. It increments the next ledger to fetch by 4 (equal to ledgers_per_file), fetching the batch containing ledger 10 and 14 resulting in the download of files 8–11.xdr and 12–15.xdr.
3. Now when the next ledger to fetch is incremented to 18, it exceeds the to ledger (17).
   At this point, the buffer stops queuing, skipping file 16–19.xdr even though it contains ledger 17 which is part of the requested range.

When GetLedger is called, the BufferedStorageBackend first checks if the current LCM object contains the requested ledger. If not, it tries to fetch the next LCM object from the LedgerBuffer. Since 16–19.xdr was never queued due to the boundary check, GetLedger blocks indefinitely when called for ledger 16 or later, waiting for a ledger that is never queued.

This issue does not trigger an error log because it is not treated as a failure which causing the system to remain in wait state.

Known limitations

N/A

[tamirms]

Could you update the changelog as well?