Add custom storage backends

[DouglasDwyer]

I've been looking for a pure-Rust, embedded key value store that supports pluggable storage backends or a virtual file system interface (my use case involves storing data to the Javascript OPFS via WASM, which requires using Javascript file system APIs rather than std::fs). Unfortunately, there don't seem to be any available - but redb looks like a great project, and it was easy to add this feature to it. This PR abstracts the file system code with a StorageBackend trait, which the user can implement in order to customize how redb interacts with the file system.

Please let me know what you think, and if there are any other improvements that I should add!

[cberner]

btw, if you run just in the root directory. It will run all the checks that the CI enforces

[DouglasDwyer]

My apologies for the failed CI runs. They were a bit stricter than I expected, and I'm developing on Windows (also do not have just installed at present) so it's a bit difficult to check for issues on other targets lol
I appreciate you re-running them for me; sorry for any inconvenience.

[DouglasDwyer]

Given the repeated issues, I switched to running the CI pipelines on my fork of redb. I managed to get all of them to pass, so the latest set of commits should hopefully pass in this repository too :)

[cberner]

Some minor change requests. Otherwise this lgtm :)

[C1710]

Sorry for asking this maybe very simple question:
Does this Trait actually directly allow an OPFS-based implementation? After all, all types from web-sys are !Send and !Sync, which is incompatible with the requirements of StorageBackend. Am I missing something?

[DouglasDwyer]

Does this Trait actually directly allow an OPFS-based implementation? After all, all types from web-sys are !Send and !Sync, which is incompatible with the requirements of StorageBackend. Am I missing something?

That's a good question. The approach I have in mind (although I haven't gotten a chance to implement this yet) would look as follows:

• A background thread is started (using the wasm_thread crate) which opens a connection to the OPFS using web-sys types. The background thread has two channels (one for reading data and one for writing data) or something similar.
• The main thread (or other thread) creates a Database with a custom StorageBackend. The StorageBackend ferries all read/write requests over the channels to the worker thread. It then waits for the results, blocking with the wasm_sync synchronization primitives.
• The worker thread uses the OPFS API to perform the reads/writes, and sends the data back to the main thread over the channels.

This approach, while roundabout, works around the web's annoying restrictions; the StorageBackend would be usable from multiple threads and synchronous, consistent with the current API.