Support for timing out / cancelling queries

[robx]

This is a minimal change to allow us to interrupt long running queries from within graphql-engine. It's meant to help address https://github.com/hasura/graphql-engine-mono/issues/1232.

It addresses the following bug:

When runTx receives an asynchronous exception while waiting for a response from the database server, it isn't interrupted promptly. Instead, runTx is blocked in an FFI call until the server responds regularly.

This change runs the FFI calls asynchronously, and interrupts them by sending a cancel message to the server. (Thus, this change only helps in case the server is responsive.)

There's a bit of discussion on alternatives in the corresponding graphql-engine RFC. In short:

• there are alternatives to unblocking the FFI calls, most notably libpq has a non-blocking mode (but this would be a far more invasive change)
• relying on async exceptions as a means of interrupting (and System.Timeout.timeout specifically) is not an obvious choice -- it might be preferable to e.g. pass a deadline to runTx instead
• by choosing to handle asynchronous exceptions according to "contract"/convention (i.e., dropping what we're doing and returning as quickly as possible), we lose the ability for the library user to determine whether a transaction was actually interrupted We've deemed these trade-offs acceptable for a first low-impact implementation of timeouts.

[jkachmar]

Yeah, intuitively I think this is gonna have to involve juggling sendQueryParams and isBusy to asynchronously issue the commands & query the status before doing the getCancel and cancel stuff that exists here.

[jberryman]

@robx sorry for the delay on this. Is there a portion of this in particular you'd want extra eyes on? interruptOnAsyncException looks well-documented (though I'm not at 100% comprehension), and the tests seem good to me

[robx]

@robx sorry for the delay on this. Is there a portion of this in particular you'd want extra eyes on? interruptOnAsyncException looks well-documented (though I'm not at 100% comprehension), and the tests seem good to me

Thanks! Nothing in particular, just the extra pair of eyes appreciated. Will validate/test this via graphql-engine before merging anyway, and even just an absence of "nooooo this is obviously a bad idea" is useful :).