Problematic `userWithId` strategy on GitLab Feature Flag

Problem 1: Users cannot achieve their mission with the current UI

Currently, users cannot specify userWithId strategy to a specific environment scope. For example, users cannot accomplish this simple task today:

• Enable awesome_feature flag on staging
• Enable awesome_feature flag for a specific user on production

This is a very common usage but we do not support today.

Because of this, we cannot dogfood our FeatureFlag feature as that it's already supported in Flipper and it's actively used in GitLab development process.

Problem 2: Data integrity problem

When user set userWithId on UI, userWithId strategy is persisted with default strategy.

Noticed at https://gitlab.slack.com/archives/CBZGR90A2/p1566526839257300

Also, when users update userWithId params, it adds default strategy as well. Is it intentional? e.g. strategies: [{"name"=>"default", "parameters"=>{}}, {"name"=>"userWithId", "parameters"=>{"userIds"=>"test,yse,testss"}}]

Since unleash-ruby-client considers the flag is ON when one of the any strategies fulfilled, the flag is ON regardless of the specified userIds.

Problem 3: The hack prevents us from dogfooding

!15500 (merged) is a hack to prevent persisted strategies from exposed as it is. This is a problematic in dogfooding issue that it misbehaves in the following workflow:

• A developer enables a feature on www-gitlab-com and gitlab projects ([{ 'name': 'userWithId', 'parameters': { 'userIds': 'Project:7764' } }, { 'name': 'userWithId', 'parameters': { 'userIds': 'Project:278964' } }]).
• A developer confirmed that the feature is stable, now wants to enable on all projects.
• A developer enables a feature on instance-wide . (Adds [{ 'name': 'deafult', 'parameters': {} }])
• It doesn't work because the default strategy is ignored by the hack

Proposal

• Let users set strategy per scope.
• Revert the hack !15500 (merged)

/cc @jagood @afontaine @ogolowinski