Support for prefetching RPMs [PoC]

[onosek]

This is the proof of concept of RPM prefetching functionality.
Design concept: #465

A new rpm package manager was added as a development version so --dev-package-managers flag needs to be activated.

• fetch-deps command will read the rpms lockfile and download listed packages and sources into the output directory structure. Also SBOM file will be generated (bom.json).
• inject-files command will create repofile for each arch and create repository metadata out of its RPMs for every repoid dir.

Maintainers will complete the following section

• Commit messages are descriptive enough
• Code coverage from testing does not decrease and new code is covered
• Docs updated (if applicable)
• Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test
  (as is the standard for Pipelines as Code)

[onosek]

• Missing unittests
• Contains some # NOTE comments - they will be removed after clarification.
• Input file source/rpms.lock.yaml won't be part of the merge. It serves just for your testing:
  cachi2 fetch-deps --log-level DEBUG --dev-package-managers rpm -source source --output output
cachi2 inject-files --log-level DEBUG output

[eskultety]

Some high-level comments that I could spot right away, will a deeper review once this is broken into more commits.

[eskultety]

None of the commits passes unit tests which causes the commits to not be bisectable. Please make sure the unit test suite passes after each commit, FWIW adding linter checks in there is a benefit - I suggest running git rebase main -x 'tox -e black,flake8,isort,bandit,mypy,py39' before pushing your changes to the branch.

The fact that tests currently don't pass for any of the commits is partially due to suboptimal logical structuring of them, IOW, I would expect a logical structure similar (doesn't need to be identical) to the following:

1. Model and interface class declaration with almost no real logic (i.e. using pass in for the interface methods)
2. fetch_rpm_source minimal implementation and base model validations
3. Implementing RPM download and verification
4. Implementing SBOM generation
5. Implementing inject_files

Unit tests should be part of each commit, reflecting the changes - you already got an implementation proposal on those so those should be incorporated in the next revision.

Lastly, the commit message subjects and bodies should not be tied to the name of the PR, but to the actual logic being implemented, i.e. an example for the above structure could be:

1. rpm: Introduce base models for RPM lockfile
2. rpm: Introduce fetch_rpm_sources (the commit message would mention model validation)
3. rpm: Implement RPM package downloads and checksum validation
4. rpm: Implement SBOM generation
5. rpm: Implement inject-files support

[tkdchen]

/ok-to-test

[eskultety]

Really mostly minor nitpicks related to wording of log messages, but other than that, this is working, doesn't crash in between commits; the commits are structured well. Anything else can be done in follow up patches as optimization/refactoring.Overall, this is looking really good, just waiting for the unit tests.

[brunoapimentel]

Leaving my round of reviews, they're mostly nitpicks and improvement ideas (all properly identified). Please, don't bother with them too much, let's focus on the few comments that are not nitpicks.

Congrats on the work here @onosek @eskultety. The code is looking much more organized and concise than the last time I reviewed it 💪.

[eskultety]

One last nitpick typo from me, but I think we're good to go -> Approve.