A build definition that we'd expect to be able to consume over grpc describes an image with one configuration and a list of operations that produce its layers. This is different from our current build logic that expects to be committing, at most, one layer for each commit operation, and which builds multi-layer images by committing at each Dockerfile instruction.

The result of this work will be an internal API call which can be used to create an image using a supplied configuration and a set of layer IDs. The image record will include the configuration blob and a manifest which refers to that blob, so that it will be visible when tools attempt to list which images are present on the system, but information about the image's layers in the manifest and configuration will not be suitable for pushing the image. Such an image will have to processed, such as in RUN-4247, in order to be copied out of local storage.

Because creating a layer that isn't part of an image, and which isn't part of what the storage library treats as a container, isn't something we can do at the buildah command line, this is going to have to be tested with a unit test.