Propagate CompressedDigest/CompressedSize when reusing data from another layer

[mtrmac]

We record (some) CompressedDigest/CompressedSize when pulling a layer from registry; but, previously, we would lose these values (and record uncompressed values) when creating a duplicate of a layer already present in storage. Eventually, the original layer might get deleted and then we would only find a match in BlobInfoCache, under more restrictive conditions.

Instead, try to propagate the value to the duplicated layer. This might not work if the layer has multiple compressed representations, but that's hopefully not all that frequent.

This activates the other half of containers/storage#1830 .

[cgwalters]

when creating a duplicate of a layer already present in storage.

For my own edification it'd be awesome if you can elaborate on why we do this somewhere

[mtrmac]

The c/storage data model is designed to work on not just overlay, but snapshot systems. (In the worst case, device-mapper snapshots, although that backend was recently completely removed. Relevant today: the VFS driver creates layers by first copying all files from the parent into the child.) In that model, a layer can only be applied on top of its “original” parent, it can’t be assembled on top of some other parent.

(That conceptual model is also demonstrated by the API shape, where Layer.Parent is a single layer ID, and immutable. Layers form a tree; it’s not a general DAG, neither are they not a pool to arbitrarily assemble images from.)