chore: sqlite framework

[SantiagoPittella]

closes #2248 and #2249

Summary

Introduces a light SQLite framework in crates/db (miden-node-db) and migrates the validator onto it, removing Diesel. It handles a connection pool, type-enforced read/write transactions, always-cached queries, a type codec, and cacheable IN-list helpers.

• The framework keeps a small pool of connections alive and hands them out. Because SQLite is blocking, the actual query work runs on a background thread.
• We dont handle raw connections. The struct provides either a read or a write transaction and get a small
  handle:
  • read(...) gives you a ReadTx. It begins a read-only transaction that is never committed, so
    nothing it does can persist.
  • write(...) gives you a WriteTx. It begins a write transaction.
• Added verbs like query_rows, query_opt, query_one, exists, count and execute (write only). Every one of them prepares its statement through SQLite's cache.
• Added a codec to convert between native data types and sql's.

The usage is like this:

// a read
db.read("chain_tip", |tx| {
    tx.query_opt(
        "SELECT block_header FROM block_headers ORDER BY block_num DESC LIMIT 1",
        &[],
        |row| row.get::<BlockHeader>(0),
    )
}).await?;

// a write (several statements in one atomic transaction)
db.write("apply", move |tx| {
    tx.execute("INSERT INTO ... VALUES (?1, ?2)", &[&a, &b])?;
    tx.execute("UPDATE ... SET ... WHERE id = ?1", &[&id])?;
    Ok::<(), DatabaseError>(())
}).await?;

Changelog

changelog = "none"
reason    = "Internal change only."

[kkovaacs]

I wonder what the cost of this hex() conversion is for BLOB values... I mean this would require one conversion per each list element in our query, but also in the SQLite query when it's comparing values, which might make this fairly expensive.

Do you have benchmarks for this?

[kkovaacs]

BTW, Diesel uses an "unlimited" cache -- we might as well just use something significantly larger here, like ~512 queries? We have a limited number of concurrent connections in the pool, so I think it's safe to do so.

[kkovaacs]

As far as I understand this (and .write()) are the only ways to execute queries on a connections. These take a sync FnOnce that gets passed the actual ReadTx / WriteTx transaction.

This is very similar to what we had with Diesel.

My problem with this approach is that this makes it pretty much impossible to implement a "one transaction per request" model where the request handle could mix sync queries with async code. For that to work we'd need to have an API that actually returns a transaction instance the RPC handler can use while handling the same request.

[Mirko-von-Leipzig]

I concur with this; I think a rough concept is:

let (write_conn, read_only_conn_pool) = database.load(<path>).unwrap();

This would also enforce that there is a single write connection only.

We're also largely "lying" about async in our current usage. The only actual async work we do is network IO over gRPC. The rest are all BS wrappers hiding the sync work - file IO, Sqlite and rocksdb are all sync operations in reality.

[Mirko-von-Leipzig]

If we reframe this as

a write transaction is a read transaction with additional permissions

then you can reduce the duplication by:

Suggested change

	/// A read-only transaction. Opened `DEFERRED` and never committed (changes roll back on drop).
	pub struct ReadTx<'t>(&'t Transaction<'t>);
	/// A read-write transaction. Opened `IMMEDIATE` and committed by the pool when the closure returns
	/// `Ok`.
	pub struct WriteTx<'t>(&'t Transaction<'t>);
	/// A read-only transaction. Opened `DEFERRED` and never committed (changes roll back on drop).
	pub struct ReadTx<'t>(&'t Transaction<'t>);
	/// A read-write transaction. Opened `IMMEDIATE` and committed by the pool when the closure returns
	/// `Ok`.
	pub struct WriteTx<'t>(ReadTx<'t>);
	// This lets you elide the entire read queries.
	impl Deref<ReadTx> for WriteTx {
	..
	}

[Mirko-von-Leipzig]

As mentioned above, I think we can collapse all of this by using Deref.

[Mirko-von-Leipzig]

That said, I'm not sure that we need these helpers? Maybe we only need to expose a query method and see how that goes?

[Mirko-von-Leipzig]

Given that the end goal is for this to only be sqlite, I don't think we need to hide it in a submodule? i.e. we could just have transaction, pool, connection etc living in the root.