Expose standalone read-only erofs image mounts or mount specs for container snapshotters

[mike-sul]

I am working on a containerd snapshotter using composefs and found a gap in the cfsctl mount API, both CLI and varlink.

IIUC, the current API creates a complete composefs mount: an overlayfs mount combining the erofs image with the repo objects directory. For writable mounts, the caller provides upperdir and workdir, while composefs-rs assembles the lower side.

A containerd snapshotter needs one level lower: a standalone, read-only erofs mount of the composefs image, without mounting the objects directory or creating the final overlayfs mount.

The snapshotter needs this because:

1. It must assemble the complete overlay lower stack itself, including committed snapshots, Docker’s init layer, or other runtime-specific lowers.

2. It normally returns mount specifications, while the mounts are performed later by the containerd engine in the target mount namespace.

3. The image-level erofs mount should be reusable across multiple per-container overlays.

container-libs follows a similar model: it mounts the composefs erofs blob separately and later includes it in the final overlay.

The containerd erofs snapshotter also follows similar pattern: it returns erofs mount specs followed by the final overlay mount spec. Also, this flow is described in the snapshotter's doc.

I see two possible API shapes:

1. Open and verify the composefs image and return a detached, read-only erofs mount of the image only.
2. Return the resolved and verified image information needed to construct a containerd erofs mount spec, including the image source and verity requirements.

Since the varlink API is being stabilized in #322, it may be worth considering this request there as well.

[mike-sul]

@hsiangkao, I would appreciate your view on the containerd side of this.

My assumption is that a composefs snapshotter returns a final overlay mount spec whose lowers include:

1. The composefs erofs metadata image.
2. The objects directory as a :: data-only lower.
3. Any additional snapshot lowers, such as committed uppers or Docker’s init layer.

What I am less sure about is how the erofs metadata image should be handled:

• Should the snapshotter return an [erofs mount spec](https://github.com/containerd/containerd/blob/b6aca07dd50288a598baadab38dcc8656c5e5327/plugins/snapshots/erofs/erofs.go#L331-L345), as the erofs snapshotter does, and let containerd perform the mount?
• Or should the snapshotter mount it once per image and reuse that mount across per-container overlays, since the metadata lower is identical for all containers using the same image?

This also affects the composefs API: the first approach only requires verified image and objects paths, while the second requires an image-level mount primitive.