get_treatment and get_treatment_with_config interface for Split and Memory Adapters

[veeweeherman]

Context

INS-1225

As the Split Adapter is written currently, it's only capable of reading from Split flags the value of being on, off, or in the control group. But Split features can have many options for treatments. We need to update the Adapters to be able to just retrieve the treatment value, if we want a fuller use of SplitIO's capabilities.

Changes

• expanding the ThisFeature::Adapters::SplitIo interface by adding #treatment_value and #treatment_config methods, which uses SplitIO's get_treatment_with_config method and returns its config or treatment name as value
• ThisFeature::Flag#treatment_value method that wraps the adapter's calling of the same method
• #treatment_value equivalent in ThisFeature::Adapters::Memory so this can be used in all environments
  • for treatment values to be configured, there is also a #enable_treatment!() method, which is similar to #on! which adds to the local storage of flag configurations and their required contexts (for which User id, etc)
  • I've purposely omitted ThisFeature::Adapters::Memory#treatment_config, because I wanted some feedback on the Memory#treatment_value implementation first
• updates to README for Memory
• if my understanding is correct, this should be a non-breaking change, because it only include additions to the gem
• TODO: update version, when changes finalized

[jhines-hover]

Depending on the reasoning for using get_treatment_with_config() we may need to eventually implement this method in this gem too.

Alternatively, we could have get_treatment (or whatever you rename it to) return an hash/object like:

{ 
  value: {{ treatment value }}, 
  config : { ... } 
}

So then it becomes (I didn't use symbols, but use whatever makes sense for Ruby):

ThisFeature.flag("gpa_cc_input_banner", current_user.id.to_s).get_treatment.value

ThisFeature.flag("HE_plan_for_dtc_org", @homeowner.id).get_treatment.config

[veeweeherman]

See SplitIO's docs on their Control treatment

The Memory Adapter doesn't mimic SplitIO exactly. With SplitIO, depending on whether or not the flag has been configured or has been configured with treatments, you'll get either "control" or "control_treatment" respectively, as a response.

I didn't know if it was important to mirror this functionality exactly for our Memory Adapter. Because these methods, and the Memory Adapter itself, are meant for use in the test environment only. And of course, because SplitIO can change their output at any time.

Aside from that, there's other details I felt like a rabbit-hole discussion could've been started from. Such as returning false or nil, from a method that is meant to return 1 of potentially many values. Values that are not a simple on/off switch. Would false mean something different from nil, when there are options like v1, v2, v3, etc

[veeweeherman]

Not for this PR, but I did notice it matter whether or not you pass the flag name as a symbol or string, in that it must be retrieved from the storage in the same way. May be a good for .with_indifferent_access on the storage hash