feat: Implement dynamic targeting key

[ricardobeat]

Description

Introduces the bucketingKey field in flag configuration. It allows the targeting key to be dynamically overwritten at evaluation time by another value coming from the context. See related issue for more info.

This is a non-breaking change.

Closes issue(s)

Resolve #2135

Checklist

• [x] I have tested this code
• [x] I have added unit test to cover this code
• [ ] I have updated the documentation (README.md and /website/docs)
• [x] I have followed the contributing guide

[netlify[bot]]

✅ Deploy Preview for go-feature-flag-doc-preview ready!

Name	Link
🔨 Latest commit	50a990ff2da213a0d954fd4544fe852a38675ce5
🔍 Latest deploy log	https://app.netlify.com/sites/go-feature-flag-doc-preview/deploys/66e4477aa21f550008d79b37
😎 Deploy Preview	https://deploy-preview-2218--go-feature-flag-doc-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ricardobeat]

Since rules don't have access to the parent flag, I had to pass the key around, there might be a better way to achieve this?

[ricardobeat]

Optimizely falls back to the targetingKey not sure if falling is a good idea when the bucketingKey required by the flag is not set in the evaluation context

I couldn't find Optimizely's reasoning for this. Here is my attempt at illustrating the problem:

The user in org1 receives the on variant; let's imagine this is a new "Team updates" section in their app. The other user in the organization is in the off variant and will never see the feature.

This defeats the purpose of the feature test, and when we set up analytics for the A/B test, we are going to measure things like users in organization who interacted with feature X. Having users randomly assigned to different variants within the same organization means we will measure a mix of A and B, making the metric not useful, or worse, silently biased if this (missing key) happens only for a small % of users.

Personally I don't see a logical reason to have a fallback, and would expect it to behave exactly as if targetingKey is missing; but would be happy if this is at least configurable behaviour.

[ricardobeat]

@thomaspoignant I've done a bit of refactoring according to the comments above:

• renamed GetBucketingKey
• removed the non-standard error
• added ErrorDetails (note: OpenFeature refers to it as 'error message' but OFREP has ErrorDetails instead)

I also took a first pass at documentation. Let me know what you think.

[thomaspoignant]

@ricardobeat do you need help finishing this PR?

[ricardobeat]

@thomaspoignant sorry, I was also on holiday the week before and just got around to reviewing this. Need some help with figuring out the tests indeed, commented above 🙏

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 92.85714% with 4 lines in your changes missing coverage. Please review.

Project coverage is 86.07%. Comparing base (ad53f58) to head (50a990f).

Files with missing lines	Patch %	Lines
internal/flag/rule.go	80.95%	2 Missing and 2 partials :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2218      +/-   ##
==========================================
+ Coverage   86.02%   86.07%   +0.05%     
==========================================
  Files         102      102              
  Lines        3743     3771      +28     
==========================================
+ Hits         3220     3246      +26     
- Misses        399      400       +1     
- Partials      124      125       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud