Use new createrepo_c API to simplify code

[dralley]

[noissue]

[dralley]

Found a bug, blocked: rpm-software-management/createrepo_c#426

[dralley]

I think it's safe to ditch this "original checksum" logic. I think the idea was to publish using the same checksums that the metadata had when it was synced. I don't know that it's particularly valuable now that we've started phasing out the legacy checksum types. The code was added back in 2020

In any event, it's a bit silly to do that for the checksum but not the compression type

@ggainey Can you think of any particular reason why we might want to prefer the original checksum types over the default of sha256?

Or maybe we shouldn't get rid of this entirely, but we can merge it into last_sync_details.

[ggainey]

So first, to make sure I'm understanding what we're doing here - original_checksum_types holds the type-of-checksum that repomd.xml declared each metadata file was summed-with, as of last-sync. Since we always "have" the metadata files post-sync, no matter what mode was used, we will always have sha256 available.

This is only used when publishing, correct?

If we're doing a full-mirror-sync, we don't recreate the metadata files - we just use whatever is there.

On the one hand - it's probably safe to remove this. On the other - the cost of carrying it is low, and every single time we have "cleaned up" code involving "old checksum decisions nobody will ever need in Pulp again", we've ended up having to put it back.

So my take is, "the code works as-is and the benefit from cleaning it up is...minimal". I'd leave it.

[dralley]

The cost in this case is that the API we want to use doesn't support picking the checksum on a per file basis. So it's either get rid of it or don't do this PR

[ggainey]

OK that def changes the math :) Using the new API is demonstrably preferable, not-using "original" is unlikely to impact us. If we take your initial uggestion (store into last_sync_details), then we have the info available if anyone cares (or, more important.y, we decide we have to "fix" something...)