Make store operations atomic

[rklaehn]

This makes store operations atomic by just using an in memory mutex.

This means that as soon as a db is being opened twice at the same time, it will be corrupted. But that is the case anyway because we are already relying on in process atomicity with the (former) AtomicU64 for the id counter.

I am working on a solution that is using rocksdb transactions on a separate branch, but it seems that this will take a bit longer because I can't get the atomicity test to pass despite using transactions with snapshots.

So this is a stopgap measure that makes our store not break until we sort things out more permanently.

It also implements n0-computer/beetle#112

Note: I tried using tokio async mutexes, but that gets you into trouble again because LocalStore is not Send.

[rklaehn]

@b5 as promised, this is the interim solution since fixing this with rocksdb transactions is not as straightforward as hoped for

[rklaehn]

@flub Was trying out tokio mutex, but when reading up on it I found this in the docs:

https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#which-kind-of-mutex-should-you-use

So they explicitly mention that using a parking_lot mutex is fine in many cases.

[flub]

https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#which-kind-of-mutex-should-you-use

So they explicitly mention that using a parking_lot mutex is fine in many cases.

Yes, I think in the design of this PR using a parking_lot mutex is probably better since it is supposed to have less overhead and they are blocking inside a spawn_blocking call anyway.

This isn't quite what they discuss in that document though, that is about when they think it is reasonable to take a (sync) mutex while executing in one of the main async runtime threads I think. Which is a bit of a different trade-off.