Changed purl-policy validation to use 'matches()' instead of 'contains(), so RegExes can be used

[malice00]

Description

Changed purl-policy validation to use 'matches()' instead of 'contains(), so RegExes can be used

Addressed Issue

Fixes #2144

Additional Details

In order to not need any changes in the database, all values will get turned into RegExes if needed --> previous behavior was 'String contains', so the values will get '.*' both pre- and appended, unless the new value is a RegEx that already has this (although this wouldn't really make a difference) or if they use anchors ('^' for start-of-line and '$' for end-of-line).

Branch includes the changes from #2333, so it should be merged first!

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[nscuro]

Thanks for the PR @malice00! 🙌

If we change the behavior of MATCHES / NO_MATCH, it should be consistent across conditions. CpePolicyEvaluator and SwidTagIdPolicyEvaluator also use it, for example.

Perhaps it would make sense to encapsulate the logic of assembling the regex pattern in a utility method, so it can be used by all conditions that support MATCHES and NO_MATCH?

[malice00]

Rebased to the current master and added a utility-class for matching policyconditions that support the (NO_)MATCH operator. Updated all those policycondition checks to use the new class.

[malice00]

Forgot to update the @since-field in the new class... I hope the new version will be 4.8.0, otherwise it's still wrong! ;-)

[nscuro]

Looks good, thanks @malice00! 🚀