Ensure per repository version structure content integrity

Unless all users do is sync, there are currently numerous ways to create repository versions that have inconsistent structure and metadata content.

Metadata content: Release

Structure content: ReleaseComponent, ReleaseArchitecture, PackageReleaseComponent

What do we mean by consistent?

The following rules are necessary and sufficient for a given repo version to be described as structurally consistent/sound:

1. For each Package, there should be at least one PackageReleaseComponent referencing that package.
2. For each PackageReleaseComponent the referenced ReleaseComponent should be present in the repo version.
3. For each PackageReleaseComponent the referenced Package should be present in the repo version.
4. For each ReleaseComponent there should be exactly one Release with the same distribution (not strictly required since Release just stores optional release file fields).
5. For each ReleaseComponent there should be at least one PackageReleaseComponent referncing it.
6. For each package with a given architecture associated with some Release via the above association chain, there should be a ReleaseArchitecture with that same distribution as the Release and the same architecture as the Package.
7. For each Release, there should be at least one ReleaseComponent with the same distribution.

Example problems caused by "inconsistent" repo versions

https://github.com/pulp/pulp_deb/issues/777

Steps we are taking to ensure consistency

• The advanced copy can be used to move packages from repo A to repo B while also "dragging along" all the structure content associated with the package.
• The structured upload can be used to upload a package to a repo while simultaneously creating structure content to go with it.
• Currently packages present in a Release, that is missing a ReleaseArchitecture for that package throw a warning during publish. They are added to the pool folder, but not to the relevant package index. (see #778)
• Release have repo uniqueness constraint on the distribution field, so we guarantee at most one Release per distribution.

Ideas to improve consistency further

• Provide some kind of validation feature
• Go over every method of adding or removing content from a repo, and make sure it ensures consistency

Start by reviewing the Release, ReleaseComponent, ReleaseArchitecture, and PackageReleaseComponent relationships and the listed consistency rules. Compare the advanced copy, structured upload, publish, and other content-addition or removal paths; done means a defined validation feature or consistent handling across those paths, with the relevant behavior covered by tests.