Storedb interface / alternate store db backends

[roberth]

Is your feature request related to a problem? Please describe.

SQLite generally does a good job of storing the store object "metadata" (ie everything except the file system object).
However, it's not entirely without issues:

• Scalability
  • cc @RaitoBezarius
• Operating on network file systems or IPFS
  • json-meta:// store #9551
• Security could perhaps be improved (for more exotic use cases)
  • json-meta:// store #9551

Possibly other issues (please link).

Relevant discussion

Describe the solution you'd like

• A parameter for nix store init to select a store db backend. Default: sqlite.

• A store settings file, akin to the binary cache nix-cache-info, but obviously more general.
  E.g. /nix/var/nix/store-settings.json

• A field in that file, to indicate which store db backend is used.

• A virtual class StoreDatabase, with implementation for sqlite.

• LocalStore/LocalFSStore only depend on StoreDatabase.

Describe alternatives you've considered

Additional context

Priorities

Add 👍 to issues you find important.

[lf-]

btw I'm not convinced that 90% of the correctness and scaling problems with the gc process are sqlite. it's likely that nix is misusing transactions, causing the store db to get a broken state. the actual deletion isn't done by a thread pool; it needs to be. and several other related things.

but determining whether the database is the problem should be empirically done first before simply trying to switch it out one for one.

[roberth]

This solution isn't meant to only solve that one particular issue; see network and security use cases in description.

Improvements to the GC are more than welcome. Best to discuss that in a separate issue or on matrix.