async BitswapStore trait

[chunningham]

It's common to have storage APIs which are async. This PR makes BitswapStore async in order to ease the integration of async storage backends. Is this acceptable or does it cause any issues aside from breaking the API?

[dvc94ch]

Much care was taken to not have to make it async. Any reason in particular you think it should be async? DBS in general provide sync apis with an async flush. Are you using a networked db like postgres?

[chunningham]

Are you using a networked db like postgres?

The plan is leave the door open to something like that, or for example SQLx. Is the problem that awaiting such an API might cause a glut of unprocessed events in the db thread?

[rkuhn]

Currently this bitswap implementation is the most primitive one, I’d call it MVP. Adding support for allocating more resources than a single thread to storage operations would be a larger change than making the DB interface async, and it would only benefit backends that can actually deliver parallelism.

Other than this, there is also libp2p/rust-libp2p#2632.

I’d say we close this issue here and have a discussion in rust-libp2p regarding how to best integrate a bitswap implementation. Once one emerges, I’m happy to hand over the crate name (if that should become relevant; although David needs to do the actual ownership change).