Synchronous version of atrium-repo

[fractalbeauty]

Following #167 and #272, I've been replacing rs_car with atrium-repo in a project of mine. In my case, the entire CAR is read into memory before being parsed, so there's no benefit to the async APIs for me. There is also a lot of required mut which is sometimes inconvenient, but I assume was done to facilitate repo writing and non-memory fetching. It would be nice to have a sync, non-mut reader for repos. But I'm not sure if it would be possible to easily support this alongside the async version.

[sugyan]

Hmm... I thought it would be used asynchronously in many cases, so I didn't really imagine that synchronous processing would be required. I would like to consult with @DrChat who implemented atrium-repo, but if we do this, I think we can implement car_sync.rs separately from car.rs under atrium_repo::blockstore and switch the implementation depending on the feature flag.

[DrChat]

So for what it's worth, I also implemented something very similar to you where you're reading the entire CAR into memory before parsing it.

This is my implementation. I'm still using the same async CarStore implementation, but with backing storage that implements a synchronous version of AsyncRead / AsyncWrite. The backing storage itself is the CAR file mapped into memory (MappedFile).

I do want to note that you have an escape hatch: if you want to substantially change CarStore for use in Repository, you can clone the implementation and change it. The only constraint is you need to implement AsyncBlockStoreRead and AsyncBlockStoreWrite.