utils: add BOOTC_EXP_EXTERNAL_CONTAINER_TOOL env override

[ericcurtin]

Add a single environment variable that allows callers to substitute an
alternative binary for both podman and skopeo without creating hard
links or symlinks on the filesystem. The _EXP prefix makes clear that
this interface is experimental and subject to change.

BOOTC_EXP_EXTERNAL_CONTAINER_TOOL defaults to the conventional tool
name (podman or skopeo) when unset, preserving existing behaviour.
Helper functions podman_bin() and skopeo_bin() are added to
bootc-internal-utils and used at every call site across crates/lib
and crates/ostree-ext.

This unblocks downstream projects that ship a single alternative
binary (e.g. dtool) in place of
both tools by pointing the env var at that binary rather than
hard-linking it into /usr/bin.

[gemini-code-assist]

Code Review

This pull request introduces utility functions podman_bin and skopeo_bin to allow overriding the paths for the podman and skopeo binaries via environment variables, replacing hardcoded strings throughout the codebase. The reviewer suggested optimizing these functions by using std::sync::OnceLock to cache the environment variable lookups and returning &'static str to avoid redundant allocations.

[ericcurtin]

So we can use tools like:

https://github.com/ericcurtin/dtool

This tool is based on https://github.com/containerd/ libraries in place of https://github.com/containers/ libraries if desired

[ericcurtin]

Could also create a build-time flag like:

cargo build --release --no-default-features --features podman

or

cargo build --release --no-default-features --features containerd

and stop shelling out altogether? Integrate the appropriate golang code directly.

[cgwalters]

Thanks for looking at this! I'm definitely in favor of making the backend more pluggable.

But I'd like to have a bit of discussion about the design - it's a pretty impactful thing. As you've implemented it so far, the impact of this on the bootc code is deceptively simple - I get why you did it that way, but debugging the layers here is a bit scary (especially the Rust -> Go via FFI, I would go for in-process IPC personally over that).

So as of recently the trend has been to support fetching via podman and not skopeo (which uses the image proxy). But that's a really large API surface of course - though one big thing there is progress reporting.

[cgwalters]

In the short term...I'm totally fine adding this almost as is just to unblock what you're working on, just interested in that larger design consideration.

Also a really big thing here is unified storage - we've been working hard on supporting that w/podman and so the direction here is more towards doing that by default. I think we should aim to match that for containerd as well, and the moment we do that it may in fact dramatically simplify things here.

We landed https://github.com/composefs/composefs-rs/blob/main/crates/composefs-storage/src/lib.rs on the composefs-rs side which gives us zero-copy handling and I think we'd want the same for containerd - but that wants some research, as I know containerd has plugins and so it may need to be handled per-plugin.

[ericcurtin]

All sounds good to me, this PR + dtool (which is basically the minimal skopeo/podman features required with containerd backend) seems like the best short-term solution and happy to follow longer-term paths.

I guess the CI failures have nothing to do with this PR.

[ericcurtin]

How I tested this in real life was with these links:

ln /usr/bin/dtool /usr/bin/skopeo && ln /usr/bin/dtool /usr/bin/podman

the env var thing is not perfect as it's hard to ensure the env var is passed everywhere. That's why some build time solution is kinda appealing. But I'm open-minded.

[cgwalters]

Do we need two env vars? How about just BOOTC_EXP_EXTERNAL_CONTAINER_TOOL the _EXP making clear this interface is subject to change, but makes it easier to experiment.

[ericcurtin]

Done

[ericcurtin]

The other possible solution would be some config file...