services/horizon: Use COPY to speed up ClaimableBalanceChangeProcessor

[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 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 FastBatchInsertBuilder for writing to claimable_balances and claimable_balance_claimants tables. FastBatchInsertBuilder uses ‘COPY' to insert into the db which is faster than using 'INSERT'.

Why

#5086

Known limitations

N/A

[urvisavla]

Since we'll be updating all change processors to use FastBatchInsertBuilder, I changed the change processor interface to accept the database session required for FastBatchInsertBuilder in both the Commit and ProcessChange (internally calls Commit) methods. This meant that I had to pass nil to the database session for the StatsChangeProcessor. Even though StatsChangeProcessor implements the change processor interface, it is different from other change processors in that It updates in-mem counters instead of storing it in the database.

This solution works, but I am not sure about the design. Here are some other ideas I had:

1. Create a separate interface for the StatsChangeProcessor because it is different from other change processors and handle it separately in the processor runner RunAllProcessorsOnLedger and RunHistoryArchiveIngestion
2. Create a separate interface for the StatsChangeProcessor and pass an instance of StatsChangeProcessor to each of the change processors, so they can update the stats.
3. Pass the database session to the constructors of the change processors that need it instead of modifying ProcessChange and Commit. This would mean that each processor would be bound to a session throughout its lifetime, which might be okay in our case.

[sreuland]

nice work, left comments for consideration on two ongoing threads related to builder interface design choices for Exec() and Reset().

[tamirms]

there are a few lint warnings about unused fields / variables. But once those are fixed, we should be good to merge!