Implement async API for random-access-storage

[bltavares]

Async omplementation last commit / built on top of many other PRs

This commit moves the API from a sync call into async functions using async_trait.

We would like to use async operations on hypercore, and it would be nice to have the underlying storage using async-io when possible. As discussed on https://github.com/datrs/hypercore/issues/97, we could change the API to use async functions on the 'ram' trait.

Async Trait methods are still unstable, but possible using the 'async-trait' crate through a macro.

This PR moves the API to use async-fns. Tests are passing.

Choose one: a 🙋 feature

Checklist

• [x] tests pass
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added

Context

• [x] Needs https://github.com/datrs/random-access-storage/pull/22
  • [x] Needs https://github.com/datrs/random-access-memory/pull/26
  • [x] Needs https://github.com/datrs/random-access-disk/pull/37
• [x] Built on top of failure to std::error::Error branch
• [x] Built on top of bump to ram 3.0
• [x] Built on tpo of compress bitfiled

Semver Changes

minor as this is a breaking change but we are below1.0.0

[bltavares]

Code is ready for review, but it needs https://github.com/datrs/hypercore/pull/102 merged to land cleanly. I will keep it as Draft until the other PR lands, as it is built on top of it.

[Frando]

I would propose to merge this an #102. We will want hypercore to be async, and definitely need it to integrate with hypercore-protocol. Keeping this unmerged makes it hard to continue working on hypercore as all PRs either have to based on this or current master as many signatures changed. We are still quite a way before a 1.0 and can refine later still if needed.