feat: add custom maven comparator

[spiffcs]

Summary

Fix for #1526.

This PR takes the recommendation from #1526 and adapts the go-mvn-version to be used as a custom comparator for matching against packages that have the JavaPkg type. Packages of type JavaPkg will no longer use the stock matcher.

The specific case mentioned in the issue has been included in both new test harnesses.

Here is a screenshot of the issues test case working as intended with the versions for jenkins-core being correctly compared. The FP is eliminated:

Related Labeled PR for updating the quality gate:

• revision: correct labels for dom4j from TP --> FP vulnerability-match-labels#116
• chore: update java match labels for new maven version comparison vulnerability-match-labels#117
• chore: update guva with correction for new maven comparison logic vulnerability-match-labels#118

Local Sample showing FP improvements with this change:

Todo

• Constraint Tests
• Version Tests
• Unit cases from https://github.com/google/osv.dev/blob/master/osv/ecosystems/maven_test.py

[spiffcs]

Putting this back in draft - I think it needs another look as I'm still getting the faulty match mentioned in the issue. While we're testing correctly against the comparator being used as intended in the unit tests, something is not hooked up correctly. The constraint is still behaving as a fuzzy constraint.

[spiffcs]

ad906d4 updates the fuzzyComparitor to trust the type of version object it accepts as an argument. Trust in this case means that it will attempt to create a temporary comparator based on the verObj type to see if Satisfied is true before falling through to the current path.

This has a minor downside. If the package being examined is not actually of the assumed type(from the verObj) , then the satisfied logic for the newly generated comparator might give an incorrect true result. If it allowed to progress the fuzzy matcher may have returned a correct false result. This all depends on the specific ecosystem's version specification.

The trade off here is that we can now allow new comparators to be tried by trusting the versionObj knows what it's looking for without an update to the version_format field in grype-db. A fuzzyConstraint is generated when this field is not filled.

The best case here is that version_format is already populated and we're using the right comparitor before having any knowledge of the verObj. This change attempts to handle the middle ground a bit better so we don't always need an update to the DB.

[spiffcs]

Blocked on anchore/yardstick#171

The following is being returned by the quality gate locally:

Failed quality gate
   - current indeterminate matches % is greater than 10%: 
   - current=10.22% image=docker.io/cloudbees/cloudbees-core-oc@sha256:9cd85ee84e401dc27e3a8268aae67b594a651b2f4c7fc056ca14c7b0a0a6b82d

Exploring the labeled data for this image shows that a majority of the Labeled data that is categorized as Unclear contains DISPUTED in the seciton. The above PR removes Unclear from the considered set of unlabeled data.