Split Store class

[Ericson2314]

The Store class is too broad. It would be nice to see it split up to separate concerns, and avoid unsupported(...) default methods.

Intuitively, we have stores than just read and write files, and store that also can do builds. The latter would have primary and secondary systems, supportedFeatures, etc. etc. in the Config class.

But it's good to think about this distinction in the context of #5025 (comment), making buildPaths a top level method that works with a variety of store for different purposes.

Now buildPaths as a top-level method is not perfect because sometimes we do want to be able to let a remote store schedule too. E.g. when there is a bunch of remote builders, many people want to send jobs to a single central scheduler and let it dispatch jobs. So we don't want to just loose the ability of today's buildPaths implementation in RemoteStore and LegacySSHStore.

That means maybe it stays a method in some class (StoreThatCanSchedule?) after all? Or is StoreThatCanSchedule really the same as StoreThatCanBuild in practice? Would LocalStore need to implement this method, or should we just downcast and use the freestanding buildPaths function if it succeeds?

I don't know the answers to these; there is a lot to think through. Perhaps there is another easier split we can start with first, to start untangling things and improve our understanding?

[Ericson2314]

Thinking about it slightly more, I think a good first step is to split out a subclass for the GC methods. It doesn't achieve to much, but also seems much more straightforward than the issues above. That would therefore serve as a good "test run" for this sort of refactor, and still do the good work of getting rid of some unimplemented calls.

[Ericson2314]

@edolstra How do you feel on ReadStore vs WriteStore: public virtual ReadStore as a split to do have GcStore?

On one hand, I think only HttpBinaryCacheStore can't implement WriteStore, so it is not that useful for categorizing implementations. On the other hand, I think it could well be used to organize with types how store are used (e.g. substitutors can be mere ReadStores), and that as Rust roughly demonstrates this is a general useful thing to do.

Also, in longer term ReadStore vs WriteStore could fit into various authentication infrastructure. (Thinking of the nexus of https://gist.github.com/edolstra/afa5a41d4acbc0d6c8cccfede7fd4792 and CA trust maps, for example. Maybe you can subscribe to certain things one cannot read from?)