(feature) Allow more variations for a flag

[thomaspoignant]

For now, go-feature-flag allows only to have 3 variations (true, false, default).
While this is fine for most cases it can be a blocker if you want to have more than that, that's why it could be great to allows to as much variations as we want.

The only way to make this possible is to introduce a new format to configure your flag.
⚠️ This feature will be a breaking change and all configuration will have to be re-written.

A proposal for the new format (here in yaml) can be:

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
  rollout:
    scheduled:
      - 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

• variations: all the possible variation and the associate value. It can still be in all available formats (int, float64, json, json array, string, bool).
• targeting: all the existing rules for this flag and associate variation if the rule match.
• defaultRule: if none of the rule in the targeting match for the user, we are applying the default rule.
• rollout: how we rollout the flag (experimetation or scheduled)

targeting and defaultRule are using the same struct under the hood and it should looks like:

// Rule represents a originalRule applied by the flag.
type Rule struct {
	// Name is the name of the originalRule, this field is mandatory if you want
	// to update the originalRule during scheduled rollout
	Name *string `json:"name,omitempty" yaml:"name,omitempty" toml:"name,omitempty"`

	// Query represents an antlr query in the nikunjy/rules format
	Query *string `json:"query,omitempty" yaml:"query,omitempty" toml:"query,omitempty"`

	// VariationResult represents the variation name to use if the originalRule apply for the user.
	// In case we have a percentage field in the config VariationResult is ignored
	VariationResult *string `json:"variation,omitempty" yaml:"variation,omitempty" toml:"variation,omitempty"` // nolint: lll

	// Percentages represents the percentage we should give to each variation.
	// example: variationA = 10%, variationB = 80%, variationC = 10%
	Percentages *map[string]float64 `json:"percentage,omitempty" yaml:"percentage,omitempty" toml:"percentage,omitempty"` // nolint: lll

	// ProgressiveRollout is your struct to configure a progressive rollout deployment of your flag.
	// It will allow you to ramp up the percentage of your flag over time.
	// You can decide at which percentage you starts with and at what percentage you ends with in your release ramp.
	// Before the start date we will serve the initial percentage and, after we will serve the end percentage.
	ProgressiveRollout *ProgressiveRollout `json:"progressiveRollout,omitempty" yaml:"progressiveRollout,omitempty" toml:"progressiveRollout,omitempty"` // nolint: lll

	// Disable indicates that this rule is disabled.
	Disable *bool `json:"disable,omitempty" yaml:"disable,omitempty" toml:"disable,omitempty"`
}

Before releasing anything

We should avoid the maximum to have a broken release so before releasing we want to have:

• A way to convert all configuration file format to the new format.
• We should be able to handle old format and new format at the same time (it is unclear yet if we want to handle both format if in the same file).
• Communicate that the file format has changed.
• Add a log with a link to the documentation to explain that you should change your flags format.
• Add a warning on top of the readme file to explain the configuration change.

[thomaspoignant]

This work is still in progress, this is a huge change a branch is open https://github.com/thomaspoignant/go-feature-flag/tree/fix/prevent-nil-error but this is a WIP.

[thomaspoignant]

remove comment

[thomaspoignant]

See progress in this draft PR