Support rechunking only new layers since FROM

[dustymabe]

From #39 (comment)

Could be interesting also to support a mode where you rechunk just those "top" layers and leave the base layers alone.

The idea here being that we leave alone the input FROM image and just chunk the added content. Benefits:

1. if you have a lot of applications images that re-use a common base, then you continue to get layer re-use (like exists today if you don't chunk)
2. this one is a specialized use case, but today we build a rhel-coreos-base layer and then an openshift-node lyaer on top of that. Servers are initially started from rhel-coreos-base layer and then switched to the openshift-node later. Today we can only chunk the base layer and not the node layer if we want layer re-use on the first switch/pivot. With this new feature we could chunk both layers independently.

Some ideas on how to implement this:

1. teach chunkah how to look at ociarchives as inputs in order to not chunk those parts
2. teach chunkah how to accept multiple filesystem trees and compute a diff. i.e. /base and /target and only chunk /target-/base and then somehow recombine the new chunked oci-archive on top of the base FROM

[jlebon]

A simpler approach I had in mind:

• chunkah build starts shipping its manifest into the rootfs it outputs itself (e.g. at /usr/lib/chunkah/manifest.json); this should be opt-in
• when splitting a rootfs which already has a manifest.json file embedded, it means we're rechunking an image that builds from the base image; treat the manifest input as if it were a previous manifest (i.e. what we'll build for Support passing previous image manifest(s) to influence packing #39); i.e. prefer group the same original components together. For this to work well, users really will want to pass a --max-layers larger than the base image's --max-layers.

This still invalidates base layers which have files that have been changed, which is both good (you still get "squashed" semantics and don't waste bandwidth) and bad (your final image loses some of the shared layers with potentially other images using the same base). But I like how the UX is pretty much transparent to end-users.