Story: As a Quay admin, I want to be able to connect CVE report coverage to the right updaters in Clair, so I can work with my networking team to allow-list the right URLs on the proxy / firewall side.

Background:

We currently provide little background on which updaters in Clair provide coverage for which operating system package managers and language package managers. While previously it was easy to decipher by the name of the updater which OS would be covered, we now have updaters like rhcc or clair.cvss or osv where it is not obvious what coverage in CVE reports they enable / which package managers they cover.

The closest we have now is https://access.redhat.com/documentation/en-us/red_hat_quay/3.9/html-single/vulnerability_reporting_with_clair_on_red_hat_quay/index#clair-updater-urls

On top of that the documentation around updaters and matchers is at code-contributor level, we need it to be at a conceptual level for the target audience of the docs which is Quay administrators. Mentioning the internal data types of Clair like IndexReport or VulnerabilityReport doesn't do anything for users. On the other hand, the documentation about the configuration doesn't seem to be complete, e.g. the updater docs refer to the RHEL-specific updater settings as an "example", eluding to the fact that there are more, but they are not documented anywhere, see https://access.redhat.com/documentation/en-us/red_hat_quay/3.9/html-single/vulnerability_reporting_with_clair_on_red_hat_quay/index#configuring-specific-updaters

In other instance we mention example configs for updaters which do not exists, e.g. here for an non-existing updater called python: https://access.redhat.com/documentation/en-us/red_hat_quay/3.9/html-single/vulnerability_reporting_with_clair_on_red_hat_quay/index#config-fields-clair-matchers

Acceptance criteria

• We need to extend this information with the package type covered by each updater.
• It needs to become clear which updaters are required for full RHEL coverage.
• It needs to become clear what OSV is covering.
• We also need to remove any mention of remotematchers now, we moved away from CRDA which was the only use case for it.
• We also need to make clear that if nothing is explicitly defined all documented updaters are running and Clair will try to reach these URLs.
• We need to document all updater-specific configuration 
• All possible Clair configuration directives and their meaning need to be documented
• The format of the documentation needs to change from tables that list field keys with relative values like .config or ..ignore_unpatched to complete YAML listings with call outs like in the OCP doc
• We need this information in the docs, not in the release notes.