Add stochastic variant provider

[data-sync-user]

For future experimentation, it will be useful to be able to reply with suggestions that vary user-to-user stochastically. We don't want an individual user to be bumped around the different variants over time, but instead want different users to have different behaviors. (It's also ok if the variant assignments drift slowly over time, as long as that is measured in hours or days, not minutes or per-request).

To achieve this, we can add a combinator provider that takes a list of sub providers with weights and names. It would use some set of inputs from the request to generate a hashed value, and use that value to select one of the providers to get a request from. We'll need to take care that the hashed value is included in the cache key.

Ideally this hashed value could be derived from a semi-durable client identifier sent by Firefox. See bug 1745053 for details about potentially adding that. Without that identifier, we should be able to use the content of SuggestionRequest, to generate a pseudo-ID. We could use the first two characters of a search query to salt that hash, so it isn't purely dependent on location, language, and browser.

The subprovider chosen should be noted via the server_variants field in the API response.

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ Michael Cooper commented:

We should consider how we might directly integrate Nimbus instead of defining our own experimentation primitives. Moving this back to Defining until we know more about the future of that.

[data-sync-user]

➤ Nive Suresh commented:

Need a concrete use case to experiment with Merino Nive Suresh