Retry queries with postgres "serializable" and "repeatable read" isolation levels

While it is possible to instruct Hasura to always use the `SERIALIZABLE` isolation level, Hasura does not provide the logic that this isolation level requires to function properly.

From the [postgres documentation](https://www.postgresql.org/docs/13/transaction-iso.html):

> The Serializable isolation level provides the strictest transaction isolation. This level emulates serial transaction execution for all committed transactions; as if transactions had been executed one after another, serially, rather than concurrently. However, like the Repeatable Read level, applications using this level **must be prepared to retry transactions due to serialization failures**

(emphasis mine)

What this means in practice is a rather simple change in the server logic: Whenever the `40001` error code is returned by Postgres, execute the same transaction until it succeeds or errors out with a different code. If you are familiar with Haskell's STM, this concept should already be familiar.

The lack of this retry behavior makes it impractical to use `repeatable read` or `serializable` in real applications with concurrency, as the error will bubble up the clients who will have no clue if the mutation should be attempted again or not.

Start by locating the server's PostgreSQL transaction handling and the path that surfaces SQLSTATE 40001 serialization failures. Confirm how repeatable-read and serializable transactions are configured, then verify that 40001 retries the same transaction while other errors still surface normally.

Written by the indexing model from the issue text.