Allow more variations for a flag

[thomaspoignant]

Description

This pull request allows to have more variation in your GO Feature Flag configurations.

⚠️ This means that we have a breaking change since last version in the flag format.
For the simplicity of the migration we gonna support the v0.x.x flag format

Format

The new format will look like this:

test-flag:
  variations:
    VariationDefault: false  # the name could be anything
    VariationBar: false
    VariationFoo: true
  targeting:
    - name: rule-number-1
      query: key eq "random-key"
      percentage:
        VariationBar: 0
        VariationFoo: 100
    - name: rule-number-2
      query: key eq "other-random-key"
      progressiveRollout:
        initial:
          variation: "VariationBar"
          percentage: 0
          date: 2021-03-20T00:00:00.10-05:00
        end:
          variation: "VariationFoo"
          percentage: 100
          date: 2021-03-21T00:00:00.10-05:00
  defaultRule:
    variation: VariationDefault
  scheduledRollout:
    - date: 2021-03-21T00:00:00.10-05:00
      variations:
        VariationDefault: true
  experimentation:
    start: 2021-03-21T00:00:00.10-05:00
    end: 2021-03-22T00:00:00.10-05:00

Pull request progress

Here is the TODO list of things required before merging this pull request:

• Modify the flag interface to prepare the new format
• Create the new internal flag format
• Return the right reason following the open-feature spec
  • Flag disable --> DISABLED
  • Experimentation rollout not started or ended --> DISABLED
  • Has targeting and used default value --> DEFAULT
  • Has targeting and match --> TARGETING_MATCH + add rule index
  • Has no targeting and used default value --> DEFAULT
  • Use default rule and has percentage --> SPLIT
• Create the new rule system where you can have multiple rule
• Add tests for this new internal struct
• Create a DTO layer to handle different flag format
• Create converts to convert from DTO to internal flag format
  • no rule and 100% --> true
  • if rule apply --> true or false
  • if rule does not apply --> default
• Converter v0 for scheduled rollout
• Unit test converter_v0
• Checks that all test in internal/flagv1/flag_pub_test.go are also in InternalFlag
• Remove flagv1 package (moved to the test folder to check that we have no regression)
• Add more test to InternalFlag (coverage)
• Update DTO to support new flag format
• Manage rollout filed that is available for multiple flag version
• Add tests unmarshal rollout
• Add tests convert v1
• Add flag validation to check if the flag is valid or not
  • percentage: validate that the sum of all percentage is 100%
  • progressive rollout: check that inital is lower than end
  • enforce a rule name when updating rule through scheduled rollout
  • targeting without query
  • rule name is unique
• Add new tests to validate the new format
• move back experimentation and scheduleRollout to the root level of the flag.
• Unit test the migration cli
• Fix cli with scheduled steps
• Add comments in internal/flag/rule.go
• Refactor docs to present the new format
• Update doc because Webhook format has changed
• Open a beta to test the solution
• Bump version of the lib in thomaspoignant/go-feature-flag-relay-proxy to be compatible with the new format.
• Update readme.md
  • Remove header in the readme.md
  • Record a new demo video with the right format

Should be done in another PR

• Rework evaluation reasons with a more fine grained results (SPLIT ...)
• Refactor thomaspoignant/go-feature-flag-editor to be compatible with the new format.
• Ensure that a format problem with a specific flag don't erase what we have in the cache

Expected Breaking changes

• FeatureEvent: version is now a string.
• Some changes in the slack notifier format.
• Logs notifier does not display the diff anymore
• Webhook format has changed
• Change TOML library

Changes include

• Bugfix (non-breaking change that solves an issue)
• New feature (non-breaking change that adds functionality)
• Breaking changes (change that is not backward-compatible and/or changes current functionality)

Closes issue(s)

Resolve #180
Resolve #293

Checklist

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

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

No Coverage information
0.0% Duplication