feat: prototype implementation of SqliteStorage

[jsantell]

MVP of a sqlite-backed Storage provider.

• Passes tests. Run cargo test --features sqlite. Test timing increased from 27s to 42s (for me).
• Uses the message_channel functionality from noosphere_ns. Moved this into noosphere_core as general utility, but as storage is a core dependency, no go. Copied over for now. Maybe a no-noosphere-dependency crate like noosphere-utils for something like this.
• Each SqliteStorage creates a background thread (well, technically SqliteStore does this) and SqliteClient reused across all shared SqliteStore instances. We could key the background thread by (absolute) path such that multiple invocations of Storage also reuse the same worker thread.
• TBD on next steps here

[cdata]

A few high-level thoughts to get us started on this...

Each SqliteStorage creates a background thread (well, technically SqliteStore does this) and SqliteClient reused across all shared SqliteStore instances. We could key the background thread by (absolute) path such that multiple invocations of Storage also reuse the same worker thread.

• We probably have to be careful to use actual threads here unless SQLite bindings give us guarantees about blocking behavior. If SQLite blocks on a thread where tokio doesn't expect blocking work to happen, we could end up with scheduling deadlocks. Remember: SQLite cannot cooperate with the tokio runtime where thread pool management / scheduling is concerned.
• I'm not sure that handling an internal thread for reads/writes is the right approach here. It seems like we can just as easily assume "do work on current thread," and then wrap the storage in a generic "operations occur on dedicated thread" thing.

[cdata]

If we have a "blocking" storage implementation, the level of abstraction where I would like to deal with that is outside of the storage implementation itself. That would give us more control over scheduling, and we could circumstantially decide whether and how to share threads.

[jsantell]

Updated the implementation to now use a connection pool (r2d2), which allows us to grab a Send + !Sync DB connection, and not block on a single connection (default pool size is 10). Additionally, some performance improvements from using WAL. Implementation is much cleaner, too.

• Connection pool implementation has 2-3x faster reads than initial worker-thread implementation.
• WAL mode has 3x faster writes than initial worker-thread implementation, and increases read speed even more.
• Even with these changes, reads 10^1 slower and writes 10^2 slower than rocks/sled implementations.
• Removed stringification of cids/utf8 -- not needed
• Use cached queries
• Ensure any user input is sanitized/checked
• Queries themselves could probably be improved
• Swapped the rocksdb CI test for sqlite temporarily

[jsantell]

Temporary