Potential concurrency issues due to pool locking implementation

I’m rewriting the locking logic in Sonic to leverage lifetimes instead of opening read/write locks manually. It’s so error prone that some issues (if true) have been lying around for a long time.

For example, in multiple places this pattern is used, where a lock is used to prevent concurrent actions like backup_item:

// in impl StoreKVPool

// Acquire access lock (in blocking write mode), and reference it in context
// Notice: this prevents store to be acquired from any context
let _access = self.store_access_lock.write().unwrap();

However, the pool looks like pool: Arc<RwLock<HashMap<StoreKVKey, Arc<StoreKV>>>>, which means StoreKVs (which contain database connections) are cloned in multiple places and can be used at any time. Because of this, one can write data in the middle of a backup (which shouldn’t be possible).

I’ll try fixing this at some point, or proving this cannot happen (because of another mechanism downstream).

This issue might be related to #274 (I can’t confirm).