feat: initial implementation of a libsql driver

[hbjydev]

This PR aims to implement #78 by introducing a new toasty-libsql driver, supporting libsql.

It uses a lot of carbon-copy code from the rusqlite implementation, as minimal changes are needed to port between SQLite APIs and LibSQL by design.

Outstanding things to check/implement;

• I don't think libsql::Database is Sync, but libsql::Connection is. However, this means we have one connection for the entire driver instance. I don't want to go as far as opening one connection per execution, but I'd like to look into some method of pooling the connections at some point.
• Token authentication to a LibSQL service needs a second parameter, but I don't know how to pass it just yet. I think some string manipulating/including the token in a query param then taking that parameter and passing it as the token might work. Implementing this via impl From<libsql::Connection> for LibSQL in the driver crate.
• I'm doing a cast from usize to i32 in the code for the driver, but I have no idea if that's sensible in the slightest; if there's a more 'safe' way to implement that type conversion I'd be very appreciative, but for now it got the code running.

The new driver currently works properly with all the example codebases, running them with --features libsql and setting TOASTY_CONNECTION_URL to libsql::memory: succeeds without any errors.

Let me know if I'm barking up the right tree here or not! :)

[hbjydev]

I didn't see the multi-thread error locally... will investigate

[carllerche]

Thanks for the PR. What are the pros / cons of libsql vs sqlite?

[hbjydev]

Thanks for the PR. What are the pros / cons of libsql vs sqlite?

So libsql primarily shines in a couple bigger places;

• Server component -- it has an HTTP implementation layer on top of the Sqlite codebase that lets you run it as a server instead of being stuck using it locally
• Ability to do multi-instance replication
• Full compatibility with SQLite because it's just a fork of it
• It has the ability to continuously snapshot itself to S3 if configured to do so
• Design-wise, it's focused on query latency and HA.
• Support for at-rest encryption

If you want Turso's argument, their README lists a few more features it adds over plain SQLite, and their 'manifesto' provides the motivation behind building it.

[hbjydev]

Also, r.e. this:

Token authentication to a LibSQL service needs a second parameter, but I don't know how to pass it just yet.

I think I might implement From<libsql::Database> to let people bring their own DB configurations...

[hbjydev]

Okay @carllerche I think I've figured out what breaks this... Apparently running libsql and rusqlite in the same thread has a bit of an issue attached; tursodatabase/libsql#526

I'm not entirely sure how to resolve this in the context of cargo test, given it just runs them side-by-side.

Would you be okay with me splitting the test command to do --feature libsql, --feature sqlite, etc. individually? The tests do pass, this is just an issue with how rusqlite links its binary from what I can gather.