feat: Add custom regex_match string comparison

[leth]

This PR

• Adds a new regex_match jsonlogic string comparison

Notes

I don't code in golang regularly so any feedback appreciated! Also, completely new to the project, so please let me know if there are any more areas I need to update!

How to test

Use regex_match in a flag targeting rule, similar to how you would starts_with etc

[netlify[bot]]

✅ Deploy Preview for polite-licorice-3db33c canceled.

Name	Link
🔨 Latest commit	a478bc62773173d3711a4f1e2121e35b2f6b6986
🔍 Latest deploy log	https://app.netlify.com/projects/polite-licorice-3db33c/deploys/690a8619edd90d0008d84001

[sonarqubecloud[bot]]

Quality Gate failed

Failed conditions
13.6% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[aepfli]

Hey thanks for the contribution. As this is adding this logic to flagd itself, a lot of providers also support in-process evaluation. Hence i think we should create an issue, to track all those changes needed for the providers and mostly to have one place for discussions etc. Can you maybe create an issue, or if there is already an issue link it please?

[leth]

Hey thanks for the contribution. As this is adding this logic to flagd itself, a lot of providers also support in-process evaluation. Hence i think we should create an issue, to track all those changes needed for the providers and mostly to have one place for discussions etc. Can you maybe create an issue, or if there is already an issue link it please?

Thanks @aepfli, I had a quick look before but didn't find one; I'll raise one later!

Do providers have the ability to identify when they don't support a particular targeting rule and need to fall-back to the server for evaluation?

[leth]

Can anyone advise on the SQ code duplication problem: Would you prefer the string comparison tests refactored for less duplication, or would it be better to keep it as-is to keep it simple?

If it's the latter, do we need to put that file on the sonar cpd exclusion list?

[aepfli]

Hey thanks for the contribution. As this is adding this logic to flagd itself, a lot of providers also support in-process evaluation. Hence i think we should create an issue, to track all those changes needed for the providers and mostly to have one place for discussions etc. Can you maybe create an issue, or if there is already an issue link it please?

Thanks @aepfli, I had a quick look before but didn't find one; I'll raise one later!

Do providers have the ability to identify when they don't support a particular targeting rule and need to fall-back to the server for evaluation?

We do one or the other, and we do not fallback to server communication if we do in-process. Hence i recommended to create a ticket. As this is a bigger change throughout the ecosystem, which we need to discuss and evaluate.