services/horizon/internal/test/integration: Use ARTIFICIALLY_ACCELERATE_TIME_FOR_TESTING in integration tests

[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 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

Use ARTIFICIALLY_ACCELERATE_TIME_FOR_TESTING=true in integration tests instead of manual close.

Why

Running the horizon integration tests with captive core enabled has turned out to be very difficult due to issues with running Stellar Core in manual close mode (see stellar/stellar-core#2778 for more details).

We use manual close mode to speed up our integration tests. Otherwise, we'd need to wait 5 seconds for every ledger close and that would result in our integration tests taking over 20 minutes to complete.

The Stellar Core team has suggested we use ARTIFICIALLY_ACCELERATE_TIME_FOR_TESTING=true instead of manual close in our integration tests because it would fix many of the issues we encountered when attempting to run the integration tests with captive core enabled.

I have verified that the execution time of our integration tests with ARTIFICIALLY_ACCELERATE_TIME_FOR_TESTING=true are still on par with running Stellar Core in manual close mode.

Known limitations

ARTIFICIALLY_ACCELERATE_TIME_FOR_TESTING drops the time between ledger closes from ~5s to ~1s, and the number of ledgers between checkpoints from 64 to 8. Horizon assumes that each checkpoint spans 64 ledgers. In a follow up commit we should make the size of a checkpoint configurable because there is code exercised by captive core ingestion which relies on the assumption that a checkpoint spans 64 ledgers.