Add a unix remote store without the filesystem required mounted

[Ericson2314]

Motivation

This allows creating a proxy to access some other sort of remote store.

For example, I talked to @kolloch about using this to talk to a daemon running as a regular user which needs to do some extra auth steps access a binary cache. The credentials should be owned by that user not root / the daemon user, and it might need to e.g. spawn some sort of "did you authorize this?" GUI.

Context

A very natural follow-up from #7912 --- now we have all four combinations of

• ssh, unix domain socket
• mounted/unmounted on OS file system

TODO needs some tests

Priorities

Add 👍 to pull requests you find important.

[tomberek]

Could this be used to implement a "prefix rewriting store"? It would keep the existing store, but then also do path rewriting for local usage.

[Ericson2314]

Perhaps? I am not quire sure what you mean.

This works just like the (unmounted) ssh-ng:// store, except it uses a Unix domain socket instead of an ssh connection.

[roberth]

Getting a sense of impending combinatorial explosion here.
Mounted or not seems orthogonal to the protocol used.
Inheritance isn't suitable for arbitrary composition of orthogonal behaviors, so this suggests that the Store hierarchy should be refactored instead, to use value composition instead of inheritance for this purpose.
As far as URIs, that could exhibit as a more regular format such as

ssh-ng://foo
ssh-ng://foo?mounted=true
unix://?mounted=false
unix://

The only remaining irregularity is in the defaults, but I feel like that's expected and part of the domain.

[roberth]

Perhaps the mount could be considered part of the protocol, and in a way it is, but then it should be part of the scheme, where we don't have a syntax for removing a protocol. E.g. ssh-ng+mount: would be ok, but unix-mount: makes no sense out of context.

Main point is the explosion of subclasses, not the syntax.

[Ericson2314]

I totally agree: we're exposing the deficiency in the current architecture. (And we're proving once again why OOP is bad / a failure --- this is supposed to be what it is good at!)

Still, I think this is useful functionality to have. And I think having a little bit of explosion to remind us that we really need to fix the arch is OK. We discussed this briefly and @roberth said then we should document that this syntax is an ugly stop-gap and better not be stabilized. Sounds great to me!

[roberth]

Well-documented, explicitly experimental stop gap is ok.

Combinatoral class explosion postponed through experimental flag