services/horizon: Change ingest/ledgerbackend/LedgerBackend.GetLedger to be always blocking

[paulbellamy]

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 updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• 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

• Added context.Context as first param to most LedgerBackend methods, so that blocking ones can be aborted early due to shutdown or request timeout.
• Remove ingest/ledgerbackend/LedgerBackend.GetLedgerBlocking.
• Change ingest/ledgerbackend/LedgerBackend.GetLedger to always be blocking.
• Add 5s timeout (with 408 Request Timeout) to exp/services/captivecore/internal/server.go's /ledger/{sequence}, so that ingest/ledgerbackend/RemoteCaptiveCore.GetLedger, can retry and long-poll until the requested ledger is ready.

Why

• We don't need both blocking and non-blocking, so it is simpler to not maintain it.
• Having it block, and passing a ctx to abort is (arguable) more idiomatic go.

Known limitations

• I tried to keep the changes as non-invasive as possible, so there could probably be more cleanup done in the -CaptiveCoreBackend.
• It would be nice to push the single-threaded ness and some of the correctness guarantees down from the exp/services/captivecore/internal/client.go into the ingest/ledgerbackend/CaptiveCoreBackend itself, to ensure we always expose the same constraints.