services/horizon: Sort trustlines by asset code and issuer

[2opremio]

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

When obtaining trustlines from the DB, for rendering into the GET /accounts endpoint, order them by asset code (and issuer) so that the output is stable (postgres doesn't guarantee a consistent ordering).

Why

horizon-cmp outputs a large amount of false positives because of this, plus it's always a good idea to generate a stable output, independent of the Horizon server used.

Known limitations

The DB query becomes slower. I pondered ordering it on the Horizon-side, but I figured a DB engine would be more efficient at this.

[bartekn]

The DB query becomes slower. I pondered ordering it on the Horizon-side, but I figured a DB engine would be more efficient at this.

I wonder how slower it would be (we should test it in staging). trust_line table doesn't contain an index that could be directly used in this query. After filtering by account_id the result set should be small enough for most of the accounts to not affect performance but I've seen Postgres not use indices it could many times.

[tamirms]

but I've seen Postgres not use indices it could many times.

that's a really good point. we can run an explain query on the staging pubnet db and see what it produces

[2opremio]

This fixed #2447

I will check the query in the staging db and report back

[2opremio]

I wonder how slower it would be (we should test it in staging). trust_line table doesn't contain an index that could be directly used in this query.

Since it doesn't contain an index, I doubt it will make things considerably worse (the table needs to be scanned anyways).