Make begin,commit,rollback cancel-safe in sqlite

[madadam]

Closes #2054

[madadam]

This fix is not sufficient. Consider a begin() is cancelled on one connection and another begin() is called on a different connection. The transaction depth is tracked per connection so this case would be missed. Need to think of a different approach.

EDIT: fixed

[madadam]

Take two. This time it should work across multiple connections as well. The idea is to try to recover from cancellation immediately as it is detected and on the same connection, not delay it until the next command (which might happen on another connection).

[abonander]

Could this be simplified somewhat if we just switched channel implementations to one that has more consistent behavior re. send()? I'm not really attached to Flume.

[madadam]

Could this be simplified somewhat if we just switched channel implementations to one that has more consistent behavior re. send()? I'm not really attached to Flume.

I'm not sure. Let's say we have a channel whose send guarantees the message is not sent unless polled to completion. Then we would be able to implement the fix described in #2054. However, there are at least two problems with it:

1. The fix implicitly assumes that the BEGIN command always succeeds. But what can happen (at least in theory) is this:

   1. begin() is called and the command is sent to the worker thread
   2. begin() is then cancelled
   3. The RAII guard's destructor is called which sends a ROLLBACK command
   4. the worker thread processes the BEGIN but it fails for some reason
   5. the worker thread then processes the ROLLBACK, rolling back an incorrect transaction

   The problem is that we don't know whether the BEGIN succeeded until we receive the response, but that can be cancelled. So the decision whether to fire the ROLLBACK can't be made solely based on whether the first send completed or not.

2. Even if this somehow fixed the issues with begin cancellation, there is still issue with commit / rollback cancellation. The problem there is that if they are cancelled, the open flag is not cleared and so the Transaction destructor sends another ROLLBACK.

[madadam]

One way to simplify this PR (in terms of number of changed lines) is instead of the ad-hoc rendezvous_oneshot channel to use flume::bounded(0) which is supposed to work as a rendezvous channel. However, I'm not sure it has the necessary cancellation guarantees.