RPM Support

Pulp (2.17) now uses libsolv as the solver to calculate dependencies when recursively copying units.
This solver is a yes--no solver rather than the best-effort solver we used to have before.
The motivation for the change is discussed on the Issue #3528.

The cleanest solution would be to include multiple repositories in the dependencies calculation, i.e as gmbnomis put it: "given source repo A and target repo B, consider the union of the B, C1, C2... repos as 'installed', where C1, C2... are the repos that would be enabled on the consumer system during DNF installation." Any dependency-solving failures would ideally be propagated back thru the recursive copy tasks result too. This solution would however imply both REST API changes as well as the recursive copy workflow change so it might not be the most welcomed idea for our users. Based on some early investigation of modular depsolving (downstream product implications), similar approach might have to be reused in Issue #3740: given the fact multiple source repositories have to be considered for modular content to resolve, multiple target repositories have to be considered, but the reasons for the multiple target repositories are still unclear to me now.

Another option might be to "fake" missing dependencies with dummy solvables providing those dependencies like DummySolvable(name='/bin/bash', fileprovides=['/bin/bash'], evr='', arch='noarch').
The solver might need to retry solving (multiple times?) before the units can be copied but the solver behavior would remain backwards-compatible which could be preferred by users. This option might be even considered in case of modular depsolving because modular content is kept separate from its dependencies in OS repo content, so the modular repos are "solo-uninstallable" by design.

Applied in changeset 740dff163e5607180c7cb3cfdc4d296c6cc288ef.