Use dnf in the container to install osbuild-depsolve-dnf instead of copying a file

[bcl]

Includes some changes to tests.

[achilleas-k]

I like this change but makes me wonder if we were (and still are) going about it backwards. Before, we were copying a script into the base container to run it and do depsolving using:

1. The script we copied in, and
2. The configurations inside the container.

Now we replace part 1 with an installation of the script. This lets us break apart the script into modules and this downstream project doesn't need to worry about that, it can just "install and run" the depsolver.

But this creates a small issue of unpredictability. There's a mismatch of sources here:

• The manifest generator (bib + osbuild/images) is defined in this repo and has an interface that talks to osbuild-depsolve-dnf.
• osbuild-depsolve-dnf comes from an rpm repository defined in the base container.

Now, to be fair, ignoring recent interface breakage between osbuild-depsolve-dnf and the code in osbuild/images (created by none other than yours truly), we're often careful about introducing changes to the interface (moreso now). But it might be the case that we need a new depsolver feature especially for BIB manifest generation that would be unavailable in, say, a RHEL 9.x version of the depsolver coming from the repositories of the base container.

So to return to my initial question about whether we're going about this backwards, I wonder if it wouldn't be easier to do depsolving outside the container using:

1. The module installed in the BIB container, and
2. The configuration from the base container copied out into a chroot of some sort.

In fact, when I made the changes to the depsolver to use foreign configs, this is exactly what I had in mind. I realise it might be tricky, because files can reference other files (gpg keys, tls certs, etc), but honestly I think it might be less painful to just copy out the entire /etc from the base container and run our depsolver there.

[bcl]

Good points! A potential issue I can see with that is that we are then using the depsolver (dnf vs. dn5) from the build container which may result in different results than it would running the right one inside the target container. I'm not sure this has ever been an actual problem though.

Another idea (that I don't really like) is to have a repo of osbuild-depsolve-dnf rpms that get updated separately and installed into the target for depsolving.

I'll take a look at flipping this around and extracting the repos into a chroot.

[bcl]

See #565