Add an implementation of kvdb on top of IndexedDB about parity-common HOT 3 CLOSED

I think the main problem is that kvdb exposes sync API like fn get(&self, col: Option<u32>, key: &[u8]) -> io::Result<Option<DBValue>>, whereas IndexedDB provides an async API with js-style callbacks.

From https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStoreSync:

Important: The synchronous version of the IndexedDB API was originally intended for use only with Web Workers, and was eventually removed from the spec because its need was questionable. It may however be reintroduced in the future if there is enough demand from web developers.

from parity-common.

Oh, I see.

Maybe a better approach is simply to keep the database in memory (like kvdb-memory), and save a serialized version in the local storage from time to time and on shutdown.

The use case is a light client whose database is probably very small. I imagine that the light client will somehow warp-sync in the future, and storing the database is mostly an optimization.

from parity-common.

While trying to make this work, I've encountered a bunch of issues:

Some problems of localStorage:

• The API allows you to use only JS string (UTF-16) as keys and values
• It usually has a limit of 10MB (https://arty.name/localstorage.html)
• localStorage API is not available in WebWorkers, meaning it's not possible to save a serialized version in a background thread.

IndexDB API is not ready yet

• one can access low-level API via web_sys, but it's really ugly
• Hopefully this will be resolved by rustwasm/gloo#68

I'm not sure what is the expected size of of the substrate light client db, but we could implement it with localStorage first and migrate to IndexDB later (I imagine having an in-memory hashmap in both cases, reading the whole db into the memory on startup and writing async in case of indexdb).

wasm-bindgen limitations

• it doesn't (and probably won't) support lifetimes in returned values (rustwasm/wasm-bindgen#423) (we have iter and iter_from_prefix methods on KeyValueDB)
• only supports c-style enums (we have a rusty enum DBOp in kvdb)
• [minor] wasm-bindgen provides a proc macro to generate all the js shims, which means it can't be used as an optional dependency on kvdb due to rust-lang/rust#29642, unless I'm missing something?

This means that kvdb KeyValueDB interface would need some breaking changes. Alternatively, we could create another (async?) interface just for the browser use-case.

EDIT: the wasm-bindgen limitations are only relevant if we want to expose the KeyValueDB interface to JS, but looks like we don't.

from parity-common.