Description of problem:
When running a task to verify the checksum of a single repository from the WebUI (WebUI > Content > Product > [click a product name] > [click a repo name] > Select Action > Verify Content Checksum) a single task to verify the checksum of the root repository in that organization, as expected.

When running a task to verify the checksum of a single PRODUCT from the WebUI (WebUI > Content > Product > [select a checkbox for a product] > Select Action > Verify Content Checksum) every repository under that product, along with every cloned version of those repositories (cloned repos being those pulp repos for content views and composite content views that get created) get a verify checksum task run against it in no particular order.

Version-Release number of selected component (if applicable):
Satellite 6.14.2

How reproducible:
Every time

Steps to Reproduce:
1. Sync a repository
2. Add this repo to a content view
3. Create 1 or more content view versions with different filters to exclude any package to cause pulp to create a clone of the repository
4. Using the 2 methods mentioned above, execute a verify checksum action on the product and the individual repository
5. Watch the tasks that spawn in foreman-tasks

Actual results:
This is a problem for the following 3 reasons:
1. As the RPMs only exist once on the filesystem for any number of repositories, only the reference for the foreman root repository should ever be applicable for the methods mentioned above.
2. Inconsistency of expectations when executing for a product or a repo.
3. Verifying Checksum a clone repository is most likely never going to be the expected use case. Likely the reason for running the verify checksum is that a package available to a client doesn't exist, match with what the repodata says it should be, or the package is corrupted/unusable. Since clones don't have pulpcore remote objects, these can't be fixed. (Unless there is some feature to refer back to the foreman's root repository that I didn't see).

Expected results:

• Short-term:
  Have the verify checksum action for both the product and individual repository only take action on the foreman root repository version and not the repositories cloned into content views.

• Long-term: Include short-term goal, and have the verify checksum flag a repository if a change occurred. Then for each flagged repository, republish repodata on all instances of the repository for the organization.

Additional info: