DataAccessorBasedStore is concurrent-unsound.

[damooo]

Description

Currently DataAccessorBasedStore takes care of much of solid-level implementation, and delegates accessing data to a configured accessor.

And current way to make the store concurrent-safe is to layer-over with a locking layer that locks only request-target. It was understood that such locking only provide concurrent-safety for representation-data, and not for solid-level semantics and storage-layout.

For example:

• Simultanious PUT on a/b/, a/b, can end up creating both aginest uri-semantics. Or Simultanious POST on a/ with slug b, and PUT on a/b/.
• Simultanious PUT on a/b/c/d or a/b.
• Simultanious DELETE on a container, and PUT on path of any of it's non-existing children/descendents.
• etc.

The contention axes are many that, it is possible to corrupt storage layout.
And any kind of layering cannot achieve concurrent-safety. Locking entire chain of containers on outer layer effectively makes store serial one.