Retryable transactions + async exception handling

[jship]

The main change in this PR is adding support for retryable transactions. For example, when using the various runSqlPool* functions at a repeatable-read or serializable isolation level, application authors need a means to retry transactions that encounter serialization failures. Without official support for this in persistent, runSqlPool* users could technically still manually catch a serialization failure exception around the whole runSqlPool* and retry the transaction, but this is a nonstarter as the connection would need to be returned then reacquired from the pool. To support retryable transactions, a runSqlPoolWithExtensibleHooksRetry function was added that takes in an exception predicate to determine retrying the transaction. The existing runSqlPoolWithExtensibleHooks is now implemented in terms of the new function.

Another change in this PR is around runSqlPoolWithExtensibleHooks's async exception handling. The previous version of this function would not run the runOnException hook when the user-specified database action was aborted via async exception, as async exceptions were ignored entirely due to use of unliftio's catchAny. This is not as problematic as it sounds on the surface: if an async exception came in, the enclosing withResource on the pool would catch it and terminate the connection. For PostgreSQL, when the connection is terminated, the database discards whatever changes were made in the transaction even though there was no explicit rollback. With the change in this PR, if users have custom logic defined in their runOnException hook on top of just rolling back the transaction, they should now be able to rely on persistent to execute this hook when the user-specified database action encounters any type of exception.

There were also multiple spots where the masking state was being restored (basically everything was in a restore except for the installation of the catchAny handler). The masking has been changed in this PR such that alterBackend is still in a restore, as is the user-specified action, but runBefore and runAfter are no longer in a restore. The previous version's restore usage came in from #1207, so I verified that the conn-killed binary still produces Right with the new masking. Additionally, it's worth noting that runOnException is now implicitly in an uninterruptibleMask (via unliftio's withException).

The PR might be easiest to review commit-by-commit, as intentionally failing tests were added prior to changes being made to the libraries.

---

Before submitting your PR, check that you've:

• Documented new APIs with Haddock markup
• Added @since declarations to the Haddock
• Ran stylish-haskell on any changed files.
• Adhered to the code style (see the .editorconfig file for details)

After submitting your PR:

• Update the Changelog.md file with a link to your PR
• Bumped the version number if there isn't an (unreleased) on the Changelog
• Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

[jship]

It's worth pointing out that the API has been intentionally kept simple here: so long as synchronous exceptions match the predicate, the transaction will always be retried. In the case of serialization failures at repeatable-read and serializable isolation specifically, the recommendation from the PostgreSQL docs and elsewhere is to retry these failing transactions unconditionally.

That guidance is what drove this simpler API, but users may have other failures (e.g. uniqueness violations) they would like to only retry up to a fixed number of times or retry based on some more sophisticated policy. The simple exception predicate approach in this PR would not work for those more complicated cases. Considering the more complicated cases are rare, it seemed prudent to keep the retry API as simple as possible for now. However, depending upon the exception predicate the user specifies, they may get themselves into a situation where persistent indefinitely retries. For these cases, they could wrap their runSqlPoolWithExtensibleHooksRetry call in a timeout.

[jship]

We've had success running these changes in production for a few months now. Is there anything I can help with in regards to moving the PR along?