Moving other crates into this one as a feature

[jalcine]

I've seen the practice of using features to enable implementations of different kinds of resources as a convention in Rust libraries. I mentioned this indirectly in chat but I'm eager to know if it's something that's welcome to merge in the disk and memory implementations to this crate as a feature.

Pros

• Core development can be quickly tested on specific implementations
• Fixes in implementations that can affect the core interface can be sent upstream quickly
• Testing everything with different forms of data can happen in one go.

Cons

• Versioning becomes very specific to the root crate and can make semver messy.
• Downstream clients (any?) could become confused with change in packaging

A compromise of sorts would be converting this into a workspace and having the other implementations be local crates, which gives us the benefits without the cons.

(Originally published at: https://jacky.wtf/2022/7/PCUV)

[ttiurani]

One issue I'm thinking about is how to get WASM build to work with features given that there's this:

rust-lang/cargo#1197

Cargo issue. The problem is that random_access_disk can't work with WASM (as there is no real disk anywhere), but hypercore should probably still expose convenience methods that use the RandomAccessDisk type.

Currently with multiple crates that is possible with this kind of Cargo.toml change, but I believe this would become harder to achieve with features due to that 1197 issue.

Of course if this kind of disk feature had also it's own WASM cfg:s so that it compiled with --target=wasm32-unknown-unknown, but just didn't do anything, then that could possibly work too. Don't know if that's confusing though.