Add arbitrary key-value storage

[HerbCaudill]

This PR adds support for arbitrary key-value storage to StorageSubsystem. The load, save, and remove methods are for generic key/value storage, and the loadDoc, saveDoc, and removeDoc methods are for Automerge documents.

For example, these will be used by the LocalFirstAuthProvider to persist the encrypted team graph that encodes group membership and permissions.

 const namespace = "MyCoolAdapter" 
 const key = "ABC123" 

 await storage.save(namespace, key, value) 
  
 const reloadedValue = await storage.load(namespace, key) 
  
 await storage.remove(namespace, key) 

The namespace parameter is to prevent collisions with other users of the storage subsystem. Typically this will be the name of the plug-in, adapter, or other system that is using it. For example, the LocalFirstAuthProvider uses the namespace LocalFirstAuthProvider.

[HerbCaudill]

Current dependencies on/for this PR:

• main
  • PR NodeFSStorageAdapter: refactor #215
    • PR NodeFSStorageAdapter: remove from cache as well as file system #216
      • PR Add arbitrary key-value storage #217 👈
        • PR StorageSubsystem: Fix bug with rapid-fire saves & concurrent reads #218
          • PR Clean up & refactor Repo #221
            • PR Proposed AuthProvider API #219
              • PR add storage to base auth provider #222
                • PR AuthProvider for localfirst/auth #220

This stack of pull requests is managed by Graphite.

[pvh]

is it worth doing an indexedDB migration to clean this up and stop squatting on the whole documentId namespace?

[HerbCaudill]

Oh I really don't think so. Maybe it would have been cleaner to do it that way from the beginning but if there's not a problem I would just leave it. As long as nobody but the storage subsystem talks directly to the storage adapters it should be fine.

[pvh]

can't prevent another tab from doing this... still probably a good idea but worth testing concurrent compactions

[HerbCaudill]

yeah - maybe create a separate issue to track that?

[pvh]

i'm not sure there's a good reason to differentiate these anymore. what do you think?

[HerbCaudill]

It's true that we're not doing anything with the information except to ensure that it's one or the other, but I think the additional clarity doesn't hurt anything & could be helpful for debugging etc.