Use fetchAndPersistBracket instead of fetchAndPersist

[skisel]

Fixes #11158

CHANGELOG_BEGIN
- [JSON API] Under rare conditions, a POST-style multi-template query backed by
  database could have different template IDs appear to be queried at different
  ledger times, if updated concurrently.  This conditions is now checked and
  accounted for.  See `issue #12672
  <https://github.com/digital-asset/daml/pull/12672>`__.
CHANGELOG_END

Pull Request Checklist

• Read and understand the contribution guidelines
• Include appropriate tests
• Set a descriptive title and thorough description
• Add a reference to the issue this PR will solve, if appropriate
• Include changelog additions in one or more commit message bodies between the CHANGELOG_BEGIN and CHANGELOG_END tags
• Normal production system change, include purpose of change in description
• If you mean to change the status of a component, please make sure you keep the Component Status page up to date.

NOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with /AzurePipelines run to
trigger the build.

[skisel]

Not sure about nested timed here, how does it work? is it fine?

[S11001001]

The trouble is that what we are wanting to measure here is the difference between time fetching for the query, and time actually doing the query (i.e. the fetchById call), and conflating the two would be really bad for the accuracy of our metrics. The best solution here might be to make fetchAndPersistBracket a little more complicated, possibly by having it take a polymorphic function ConnectionIO ~> ConnectionIO as an argument (it seems worse to have it talk about metrics itself).

[S11001001]

@realvictorprm fetchAndPersistBracket #10617 changes our approach from "do all fetching, then query" to "fetch, then query, then check consistency, then if needed catch-up fetch, then query..."

What is the most useful way to present these metrics? There's some case to be made for aggregating fetch time for a particular request, since either we roll back or keep the prior fetch and catch-up depending on how recoverable the inconsistency was. It's more difficult to justify aggregating query time, since we always discard all query results if the consistency check fails and only ever use the last result. On the other hand, the time for those discarded queries does contribute to the request time; there is no way to parallelize it with the "good" query.

Should we record each fetch separately? Add them all up? Discard or keep the bad queries? Spend any time at all tabulating the consistency check (it is "just" a select on the ledger_offsets table)?

[S11001001]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[S11001001]

@skisel I reverted the contract ID and contract key lookups; explanation in comments.