feat: search rules for data-driven distro matching customization and lookup

[kzantow]

This PR adds DB-driven search rules to allow queries to include additional data sets based on per-package matched values (e.g. version containing .rf#, echo#, ubuntu#), results are assigned priority to assess vuln applicability across multiple conflicting results, and the PR uses these changes to support RapidFort curated-image advisories.

Search rules

• New v6 SearchRule model and store (DB schema 6.1.10). Each Match*/Exclude* predicate (distro name/version, ecosystem, package name/version, etc.) is an exact value or a regex. Every rule needs at least one indexed literal predicate (e.g. at least package type deb) to limit the impact to matching performance
• A matching rule replaces a search with altered criteria: distro and/or package name, tagged with the rule's priority (search.RuleCriteria); multiple rules can match a single query to include the original query or different, lower priority data sets
• Rewrites are applied centrally to most matching processes (apk, dpkg, rpm, language, CPE) use them without per-matcher code

Match behavior with conflicting evidence

An increasing problem we haven't properly handled is a single package having multiple applicable records describing the same vulnerability: an APK package might have NVD, Alpine, and a derivative distro back-porting fixes at a faster cadence, where Alpine and the distro only report fixes rather than disclose vulnerabilities. Deciding across these disparate data sources is increasingly important in the current landscape and this PR attempts to solve this with a few exceptions noted below. The general approach which also accounts for search rule matched records is:

• New result.Rank: when results for one vulnerability disagree, a result from a rule's search beats the package's own result. After that, the higher rule priority wins, then the stronger match type
• SplitVulnerable sorts records into vulnerable and not vulnerable based on heuristics and rankings:
  • The highest-ranked search with a range that covers the installed version decides
  • Unaffected (NAK) records deny regardless of rank
  • An advisory whose fix is exactly the installed version suppresses only candidates whose CVEs are all covered by that fix

RapidFort

• New rapidfort-* distros (alpine, ubuntu, redhat, including Ubuntu variants) and a DB transformer for RapidFort vuln data
• A distro identifier remaps the detected base distro to its RapidFort equivalent when image labels or marker files show a RapidFort-curated image. It drops base channels such as esm/eus. Config: distro-identifiers.rapidfort.apply:auto|never (default auto)
• Search rules layer RapidFort more specific release streams over base streams, so a RapidFort fix or NAK overrides the upstream record

Misc. output fixes

• relatedVulnerabilities is sorted, so --by-cve picks a stable canonical CVE
• Fix versions that are equal but spelled differently are deduped (e.g. 0:1.2-3 and 1.2-3)
• Reported fix versions at or below the installed version are dropped

Notes

• Quality gate needs:
  • fix: include qualifiers for unaffected packages #3734 (merged) to be released through grype-db and upgrade quality gate to a db built with qualifiers properly in unaffected records
  • Update Oracle Linux labels vulnerability-match-labels#209 -- submodule is pointing to this PR's commit
• Not in this PR:
  • refactoring ESM, EUS to use the late vulnerability determination from channels and base results
  • removing RootIO custom code that can now be handled by search rules

[willmurphyscode]

This is subtle that it's explicitly nil, vs just len(rows) == 0. Do we know whether at https://github.com/anchore/grype/pull/3751/changes#diff-20f991f6ce703181473acf0176595a408530d7b0678faa25905642a248557e71R28 gorm will init the row slice? I think maybe it will: https://github.com/go-gorm/gorm/blob/v1.31.2/scan.go#L295-L303

[kzantow]

it is explicitly set to nil if there is an error to fall back; added a comment so this is more clear

[willmurphyscode]

What is the intended behavior if the table is present but the query works, but the table is empty?

[kzantow]

if the table is present but empty, it's intended to mean no search rules -- the hardcoded ones could be wrong. I don't know that's the right behavior, but that's the reason for the current implementation

[willmurphyscode]

I think migrating the db will create the empty table? So if a new client imports an old DB, the table gets created as empty instead of with defaults. If the table is present at DB build time but empty, it will correctly get zero rows, but I'm not sure it's correct for a table that's absent at DB build time (because grype-db is behind, for example) to get zero rows.