Description of problem:
Playing with pulp-3 in Sat6.9, there is a trivial reproducer when publishing a CV with a typical CV filter AND depsolving enabled causes 'rq' process/broker to consume arbitrary huge amount of RAM.

This can easily lead to OOM killing 'rq' and CV publish fail.

The CV details:
- use just RHEL7 repo in the CV
- enable dependency solving (this isnt required for this specific minimalistic scenario, but assume one having a CV with multiple repos incl. RHEL7 - then depsolve makes sense)
- apply filters:
  - include all RPMs with no errata
  - include all errata published before 2021-05-01
  (- include all modules until the same date - this can be almost surely ignored)

Publishing this CV, 'rq' consumed 21G RAM until OOM killed it:

May 28 22:23:47 pmoravec-pulp3 kernel: Killed process 10890 (rq), UID 1000, total-vm:21678888kB, anon-rss:21179192kB, file-rss:0kB, shmem-rss:0kB

Disabling depsolve=true, no such issue happens.


Version-Release number of selected component (if applicable):
Sat6.9.2
libsolv-0.7.17-1.el7pc.x86_64
python3-rq-1.5.2-2.el7pc.noarch
python3-pulpcore-3.7.6-1.el7pc.noarch
python3-pulp-rpm-3.10.0-1.el7pc.noarch


How reproducible:
100%


Steps to Reproduce:
1. Sync RHEL7 repo from CDN
2. Create and publish a CV like described above, or with hammer commands in detail:
 content-view create --name CV_RHEL7_yes_include_2021-05-01 --organization-id=1 --repository-ids=1 --solve-dependencies=yes
 content-view filter create --organization-id=1 --content-view=CV_RHEL7_yes_include_2021-05-01 --name=include_base --inclusion=true --original-packages=true --type=rpm
 content-view filter create --organization-id=1 --content-view=CV_RHEL7_yes_include_2021-05-01 --name=include_errata --inclusion=true --type=erratum
 content-view filter rule create --organization-id=1 --content-view=CV_RHEL7_yes_include_2021-05-01 --content-view-filter=include_errata --date-type='updated' --end-date='2021-05-01'
 content-view filter create --organization-id=1 --content-view=CV_RHEL7_yes_include_2021-05-01 --name=include_modules --inclusion=true --original-module-streams=true --type=modulemd

 content-view publish --name CV_RHEL7_yes_include_2021-05-01 --organization-id=1 --async
3. Wait few hours and check /var/log/messages .


Actual results:
'rq' will consume 20G+ memory.


Expected results:
Much less memory requirements of the process / broker.


Additional info:
There is some additional dependency solving problem about (wrongly) unsatisfied dependencies, that *might* be related to this - I will file that in a moment.