services/horizon/internal/db2/history: Implement loaders for assets, claimable balances, and liquidity pools

[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

Implement loaders for assets, claimable balances, and liquidity pools.

Why

See #5015 for motivation.

Known limitations

[N/A]

[sreuland]

is there a functional pattern that could help drive the required timing/coordination between methods more from compile time, like GetNow as an instance returned from Exec:

type GetNow(id string) int64

func (a *LiquidityPoolLoader) Exec(ctx context.Context, session db.SessionInterface) (GetNow, error)  {...}

[tamirms]

we will only invoke GetNow() indirectly when the futures are are serialized into SQL statements. I could make GetNow() a non-exported method so that the only way it is called is through the futures. Do you think that would be better?

[sreuland]

yes, that sounds good approach, might prevent incorrect usage later, thanks!

[sreuland]

great work, good dialog about code duplication in the loader, refactor ideas, room for iterations on that later.