Unexpected behaviour creating identity overrides for control value of MV features

[matthewelwell]

To reproduce:

1. Create an MV feature
2. Create an identity override for the MV feature which selects the control value

Note that when testing, we should also validate the behaviour when updating an override for an MV feature.

Expected behaviour:

Retrieving the features for the identity always returns the control value

Actual behaviour:

I haven't quite worked out the full behaviour yet. It seems like, because the override still exists, and has a "feature_state_value" it is using that but what I can't work out is at which point(s) the FE is sending the "feature_state_value" - this might be on creation of the override or update perhaps, but it seems inconsistent.

Possible solutions:

1. When creating an override for an MV feature, the FE should always send a full complement of "multivariate_feature_state_values". When creating an override for the control value, the "percent_allocation" should be set to 0 for all values.

Other solutions considered:

1. When creating an override for an MV feature, the FE should always send the value of the MV option as the "feature_state_value". Having considered this, this would be a very bad idea since, if the values of those options change, the override would still be returning an old value.

[matthewelwell]

Having tested the possible solution given above, this doesn't seem to work and it looks like the API uses the value from feature_state_value. This is likely because of the fact that the 'control' value is just the feature_state_value on a multivariate feature state.

Based on this, I think we likely need to look at this from an API perspective before looking at it from the FE.