support/db: Support concurrent queries in a transaction

[bartekn]

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.

Summary

support/db.Session did not support concurrent Exec/Query queries sent in a DB transaction. This commit adds support for this.

Close #1836

Goal and scope

Postgres protocol does not allow sending Exec query results from previously sent Query haven't been fully read. This issue manifested itself when a PR that's sending read and write queries in multiple goroutines was merged.

To fix this a new wrMutex was created and added to Session. wrMutex works exactly like sync.RWMutex except lock can be held by an arbitrary number of writers (readers in sync.RWMutex) or a single reader (writer in sync.RWMutex). In Session, before each query we check if it's sent in a transaction and, if so, we call execLock for Exec calls and queryLock for Get and Select calls. This way, only a single Get/Select can be executed at any given time but multiple Exec will work concurrently. This shouldn't affect queries that run outside a DB transaction.

More info: lib/pq#81 lib/pq#635

Why was it working before?

It was working before because there was no code running both read and write queries concurrently:

• In Horizon actions DB transactions are not used so are executed in separate DB connections.
• In the new ingestion system pipeline, up to services/horizon/internal/db2/history: Asset stats ingestion #1810, we were only writing data concurrently.

Known limitations & issues

I confirmed it fixes #1836 but it changes the criticial code used by multiple apps. We should test it extensively before merging.

[bartekn]

Closing in favour of #1837.