Consider hypercore dependency injection

Just tossing this one out there:

Replacing the top-level storage parameter with an asynchronous hypercore factory might be a nice abstraction for a few reasons:

First, storage management is already performed by hypercore, and is effectively duplicated in hyperdb -- it'd be nice to be able to write a single module that wraps storage (and networking) for a set of hypercores, then passes those up to hyperdb.

Second, introducing one level of indirection would allow us to inject objects proxies that mirror the hypercore interface. As an example use-case, consider applying permissions to local dbs (i.e. you have N writable dbs being accessed by K local programs, where only P < K programs should be able to perform writes):

Currently one would have to replicate the writable db into a read-only copy before passing it to a restricted program (correct me if I'm wrong, but I believe other approaches could be circumvented by inspecting the hypercore object). With a proxy, direct access could be transparently replaced by RPC calls that contain an auth token, for example.

Start by tracing hyperdb's current top-level storage parameter and its hypercore integration. Review how an asynchronous hypercore factory, proxy objects, storage management, and permission handling would fit together. The issue does not define acceptance criteria, so completion would require a design decision and agreement on the intended abstraction.