[Additional Layer Store] Use TOCDigest as ID of each layer

[ktock]

Needs: containers/storage#1924 and containers/image#2416

This commit changes stargz-store to use TOCDigest as the layer specifier.
For example, the extracted view of a layer diff contents is provided in the following path:

 <mountpoint>/base64(imageref)/<TOCDigest>/diff

When an access happens to a layer, stargz store searches the layer that has the TOC matching to the specified TOCDigest.
If it fails to get the layer, stargz-store returns EIO.

[mtrmac]

(I’m afraid I know nothing about this codebase; I could be completely off-base.)

[mtrmac]

What happens when the manifest contains multiple layers with the same compressed digest but different TOC digests?

Note that such a situation can “legitimately” happen, where all digests validate, if an attacker decides to create such a multi-TOC layer; and the TOCs can differ.

Whether the compressedDigest is validated or not, c/image image signing relies the ALS backed enforcing exactly the TOC digest provided over the FUSE API. Looking at how resolveLayer uses the layerDigestToTOCDigest map, it seems to me that the data flow goes (TOC digest -> compressed digest (?) -> possibly-different TOC digest) and potentially uses the wrong TOC digest for some operations.

Here, getCachedLayer is called with the layerTOCDigest and not the original tocDigest. Luckily, it is followed by a Info().TOCDigest == tocDigest check, but still, the opportunity to replace the TOC digest worries me.

---

In principle, ((repo, compressed digest) <-> TOC digest) is an N to M mapping. It’s reasonable to assume that the same compressed digest implies the same TOC digest, except when under attack; the same TOC digest can legitimately map to different compressed digest values (in the same repo, or in different repos).

[ktock]

Removed layerDigestToTOCDigest.