Possible improvement for the manifest file

[apirogov]

The manifest exists for the usecase of patching a container that is locally not available.

But there is another possible use for the manifest: avoid opening all containers to access a single data entity.

Each data entity exists only in one file - by definition the most recent patch defining it. Therefore, when requesting data from a path in an immutable container, we can avoid opening all the files, constructing the overlay, etc and simply serve the data from the correct patch.

To do that, the manifest should store patch index + patch containers UUIDs (or something like that) which helps figuring out which file to open for serving a given path.

Some careful thought is required so that this works smoothly and correctly when combined with stub containers and merged containers.
In these cases the skeleton is flattened (so you cannot use a stub to infer correct files to use), in stubs we must preserve the patch indices of the original patch sequence! With merged containers its not really clear what should happen - the same patch on a merge or the same patch on the original container sequence are observationally equivalent.

Maybe, in fact, this info should be stored ad-hoc for a specific context, and not added to the manifest. In any case, this needs further thought.