Libsql client: execute batch

[Horusiath]

Add support for executing batch statements (in rusqlite fashion) to libsql client: including Cloudflare compilation target.

There was a small mismatch in an API:

• rusqlite expects execute_batch(sql: &str): all statements are glued together into a single string.
• Hrana protocol expects execute batch to give an array of individual statements to execute.

This means that we need to at least parse requests on the client side (which has its upsides and downsides), so I pulled sqlite3-parser out of the replication module and make it a dependency on hrana feature as well.

/cc @psarna @LucioFranco

[psarna]

@Horusiath I think everyone agrees that rusqlite's batch API that accepts a single string is not the best match for us, so perhaps we should only add it as a compatibility layer? By that I mean:

1. Have a proper function that accepts a slice/array/whatever of statements (related: libsql crate: allow passing multiple statements with bound parameters to execute_batch #562)
2. Based on that function, we also add one that accepts a &str of glued statements, and does all the unfortunate reparsing.

Then we can get our users used to the "proper" API, and gradually deprecate the &str one, which doesn't accept bound parameters either, so it's a security issue as well, begs for SQL injection.

[psarna]

we already have raw_batch from the libsql-client-rs days, so I think it's only a matter of exposing another function that accepts a slice of statements and uses raw_batch underneath?

[LucioFranco]

LGTM! Really nice work!

[LucioFranco]

When does this warning trigger? We could use cfg_attr to only enable this in certain feature flag situations.

[Horusiath]

It's mostly happening since I moved the parser.rs as an entire file, however in context of hrana we're only using a small subset of its functions.

[LucioFranco]

is this rustfmt making this change? Seems odd since I should be running it on every save.

[Horusiath]

Apparently so. I have fmt running on every file save.

[LucioFranco]

@psarna I think you're right, we should instead accept a IntoStatements trait that we can impl for &str and IntoIterator<impl Into<Statement>>. That said, this is fine for now, I want to ship this instead of waiting for that change.

[LucioFranco]

and we already have a separate issue for it #562, lets do this in a follow up when we have time.