Separation of concerns: storage providers should not know about their mount path

[butonic]

Currently, the mount path of a storage needs to be configured in two places: the storage registry and the storage provider.

The gateway uses the storage registry to route requests to the correct storage provider.

The storage provider wraps and unwraps the internal path provided by the storage driver (eos, local, oc, ...) by removing or adding the mount path.

This model allows configuring two storage providers with the same mount path and mount id, which might lead to confusion or conflicts. It is no longer clear which storage provider is responsible. Even if it is supposed to represent a load balancing configuration that configuration is better stored in the storage registry.

The storage providers should only be concerned and know about the namespace within them.

How the global namespace is composed is the responsibility of the storage registry.

The wrapping of the paths providers by the storage providers should be moved to the gateway, which already has the mount path and mount id information from storage registry (that is always fetches to determine which storage provider to use).

Related PRs:
#562
#577
butonic#1

[labkode]

This allows configuring two storage providers with the same mount point, which might lead to confusion or conflicts. It is no longer clear which storage provider is responsible. Even if it is supposed to represent a load balancing configuration that configuration is better stored in the storage registry.

Having two storage providers providing the same mount path and different mount ids is really important in sharding scenarios where you hide under the same namespace (/eos/user/) multiple storage providers. So for example, /eos/user/h/hugo will go to storage-h and /eos/user/j/jorn to storage-j, that they both present /eos/user as their path but different mount ids.

Of course, this model is also plausible in the model you are proposing, and it may even be simpler.

Once we have the MVP we can jump again to this, I find very interesting and what you are proposing it may simplify some logic.

😄

[labkode]

As discussed in #601 it makes lot of sense