services/horizon/internal/db2/history: Include lower bound on descending history queries

[tamirms]

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

Include a lower bound on queries for the history endpoints which fetch rows in descending order. The following endpoints have been modified to include the lower bound:

/transactions
/ledgers
/effects
/operations
/trades

Why

In the case where a lot of history has been reaped when running a horizon instance with limited history, there will be a large amount of rows which will be deleted from the history tables. These rows will still be present in Postgres until they get vacuumed at which point they will be removed from the tables and indexes.

So, for example, if you query for transactions in sorted order, postgres will be need to sift through and discard rows which have been deleted. This can result in the query timing out if there is a large amount of deleted rows in the search. We can avoid having to sift through deleted rows by including a lower bound beyond which there should be no deleted rows. We can use the oldest ledger in the horizon db as the lower bound.

Known limitations

[N/A]

[urvisavla]

Looks good!