Add Exqlite.Sqlite3.interrupt/1.

[ColaCheng]

We encounter the db connection can not be closed when a long-running query gets a timeout(Ecto environment) but the query is still running in the background and takes the CPU resource. For this function, we can manually trigger and force-stop the query. Then we can close and release the resource successfully.

Ref: https://www.sqlite.org/c3ref/interrupt.html

[warmwaffles]

@ColaCheng yes I've been wanting to add this. Although it will not solve the issue of that long running query in the background because of the connection pool. If your connection pool is 2 then there is no guarantee that the interrupt will be routed to the problematic "connection".

That being said, thank you for implementing this and I'll get this merged. 😄

[warmwaffles]

Released under v0.21.0

[warmwaffles]

@ColaCheng we are starting to see some weird issues with interrupt here in #315

Per the documentation:

** ^It is safe to call this routine from a thread different from the
** thread that is currently running the database operation.  But it
** is not safe to call this routine with a [database connection] that
** is closed or might close before sqlite3_interrupt() returns.

This means that if you call interrupt at just the right moment before the connection is torn down, it'll fall into undefined behavior territory. I believe this is only visible in tests due to how rapid connections are stood up and torn down.

Have you ran this in production and noticed any sort of sigaborts?

Edit: I'm fairly certain it's happening here

      Process.sleep(100)
      :ok = Sqlite3.interrupt(conn)

      :ok = Sqlite3.close(conn)

The close is called immediately after interrupt which I believe is what the docs call out for. I'll need to add documentation about calling close on the connection.