Make KeyValueAccess "rooted"

[tpietzsch]

We are in a slightly weird situation currently:
There is only one FileSystemKeyValueAccess for all datasets on local (or mounted) file systems,
but there are many AmazonS3KeyValueAccess (for example), typically one per dataset.
(Also the cloud KVAs contain bucket which I would consider part of the dataset URI, while file system KVA doesn't have anything like that.)

Both @cmhulbert and me were thinking about having more than one file system KVA.
Most recently, this came up in the context of file locking behaviour (#204).
It would be nice to be able to configure an IoPolicy per Dataset.

I think that we should explore a design where KeyValueAccess always contains a containerRoot.
All keys would be relative to this. I think this would simplify typical usage a lot.

Caveat: If we make this change, there should be a way of constructing a KeyValueAccess directly, because it is used externally.
For example https://github.com/JaneliaSciComp/multiview-reconstruction uses it to access XML files (that are stored outside the dataset root).
(JaneliaSciComp/multiview-reconstruction#61 was when I last ran into this KVA weirdness)

It would be nice if the N5Factory conveniences would be available for creating KeyValueAccess (rooted at a given URI).
Maybe it should also be possible to get a new KeyValueAccess at a relative path with respect to an existing one?

[cmhulbert]

Some historical context as well. Until recently FIleSystemKeyValueAccess was built with a passed in FileSystem instance. This was initially intended to be the way that KeyValueAccess was used. The idea was to emulate a FileSystem with other non-file backends (like AWS, Google Cloud) by providing a FileSystem that wrapped the backends. After exploring this, we found no good existing FileSystem implementation over remote backends, and decided to implement our own. This inverted the interface a bit though, and instead of accessing cloud stores as file systems, we ended up accessing file systems as Key-Value stores. That's part of the reason there are still to this day some file specific operations in the KeyValueAccess interface (isFile, isDirectory, createDirectories, etc.)

We removed the passed in FileSystem as a recognition of how it's being used now, and a recognition of how it was already being used (via Files and Paths methods, which use internal FileSystemProviders).

To make the cloud systemd consistent in terms of what parameters we wanted to pass for the keys, we needed to introduce some state for them, to have a base URI to compose the keys against. For Filesystem we don't need to do this sense we have single root per file system (at least on linux) but this has made the FileSystem implementation both quite different, and bit more complicated, than the cloud store backends.

I'd also be in favor of having a containerRoot per KVA (we sort-of do this already with an empty string param forkva.uri("") which returns the absolute URI of the directory you created the FileSystemKeyValueAccess) and making the KVAs N5Container specific. It would also enable us to do more granular KVA work at some point if desired, such as Read/Write separation, or Windows/Linux specific variants to make the path handling methods less complex.

[cmhulbert]

related, but probably a separate issue. It may be useful to make all N5Reader have a keyValueAccess method if we do this. I think only HDF5 currently is not (as far as the main implementation go) and it would be nice to always be able to get a KVA from a N5Reaader for low-level optimizations

[cmhulbert]

It would be nice if the N5Factory conveniences would be available for creating KeyValueAccess (rooted at a given URI).

It's not via N5Factory since it's separate from N5, but there is already a public way to do this via n5-universe's KeyValueAccessBackend#getKeyValueAccess.

/**
	 * Test the provided {@link URI} to and return the appropriate {@link KeyValueAccess}.
	 * If no appropriate {@link KeyValueAccess} is found, may be null
	 *
	 * @param uri to create a {@link KeyValueAccess} from.
	 * @return the {@link KeyValueAccess} and container path, or null if none are valid
	 */
	@Nullable
	public static KeyValueAccess getKeyValueAccess(final URI uri, boolean readOnly) { ... }

the readOnly param is new, but the method has otherwise been there for a while