empty_config_descriptor doesn't create an empty descriptor

[ariel-miculas]

The empty descriptor is described in the image manifest doc.
I suggest we change the new_empty_manifest function to return a manifest with an empty config and to change empty_config_descriptor to create an empty config.
It would look something like get_empty_manifest from PuzzleFS. One caveat is that we need to write the actual empty descriptor in the sha256/blobs directory, otherwise other tools complain about the OCI dir structure integrity (e.g. skopeo), since all the blobs referenced from the metadata must exist on the disk.

[ariel-miculas]

Well ideally we would use the typestate pattern and have new_empty_manifest return an ImageManifestBuilder<Incomplete> which would then build() an ImageManifest<Incomplete>. Then, insert_manifest_and_config would accept both an ImageManifest<Incomplete> and an ImageManifest<Complete>, but insert_manifest would only accept an ImageManifest<Complete>.
There would also be another function which would take an ImageManifest<Incomplete> and turn it into an ImageManifest<Complete>.
Of course, this is too convoluted and would require changes to the entire oci-spec-rs design. What I was hoping to address with this is the comment from empty_config_descriptor:

/// This digest should never actually be used for anything.

because the type system wouldn't allow you to forget to set an actual valid config.

Implementing my previous comment:

we need to write the actual empty descriptor in the sha256/blobs directory

would be counterproductive because we would then have to delete the empty descriptor when the user would replace the config with its own.
Maybe we can still change the dummy digest with the digest of the empty config (sha256("{}")), though I'm not sure if it brings any value.

[cgwalters]

Well ideally we would use the typestate pattern

I think that one snowballs in general to youki-dev/oci-spec-rs#242 right?

would be counterproductive because we would then have to delete the empty descriptor when the user would replace the config with its own.

Eh, if we "leak" an empty config descriptor by default that doesn't seem like a big deal. In the general case we need GC (which we don't implement here yet).

[ariel-miculas]

Ok, then short-term I will implement the solution which writes the empty config into blobs/sha256 and we live with the two bytes occupied by the {} blob. For the long-term we'll explore the type state builder idea.