cmd-{fetch,build}: strip out digests from lockfiles

[jlebon]

The digest fields in lockfiles have been more trouble than they're worth
so far. The major problem is signing: adding a signature to an RPM of
course changes its digest.

There are two main issues. The first is that when adding an override,
there's no way to know the digest ahead of time since the package isn't
signed yet. It becomes signed when the override is accepted and tagged
into the pool.

The second is that the same package NEVRA may be present in different
repos and signed with different keys, resulting in different hashes,
even if the payload is the same (for more details on this case, see
coreos/rpm-ostree#1927).

One could add repo origin information as part of the lockfile, but that
does not correspond to what we actually do in FCOS, since packages
initially come from Bodhi, and are then imported into the pool (and even
then, there's no guarantee that the package isn't already there with a
different signature).

A possible solution is to instead use the CPIO payload digest, but that
information is not part of the repo metadata, so it'd require some work
for rpm-ostree to download the packages and select the right one. Not
especially hard, but definitely non-trivial.

In practice, we don't really need digests in the lockfile. For repos
which don't use GPG checking, it could provide some security benefits.
Though in our case, GPG verification is turned on for all the repos
anyway. But more importantly, all our data comes from Koji, which
forbids buildings two packages with the same NEVRA.

We could fold this into rpm-ostree under a new flag, though I think its
current behaviour makes sense overall. It just doesn't work well for us.

[jlebon]

This is blocking the FCOS move to f31. Open for discussions though if you have some other ideas!

[dustymabe]

LGTM

[dustymabe]

@jlebon - any reason not to merge?

[jlebon]

@jlebon - any reason not to merge?

Nah, just wanted to give time for anyone else to chime in. OK, let's do this!