We're discussing running the addon experiment with another treatment branch where the score of addon suggestions needs to be different from the other treatment branches.

This adds a quickSuggestScoreMap Nimbus variable that lets experiments
override suggestion scores. It maps from telemetry types to score values. For
example:

"quickSuggestScoreMap": {
  "amo": 0.25,
  "adm_sponsored": 0.3
}

In this example, addon suggestions will always have a score of 0.25, and
sponsored suggestions will always have a score of 0.3. Of course, different
branches within an experiment and different experiments can set different
scores.

While working on this, I saw we have a bug when we try to look up the
BaseFeature for a result. To do the lookup, we look up the result's
telemetryType in FEATURE_NAMES_BY_TELEMETRY_TYPE. That's a problem for adm
suggestions because the telemetryType will be either adm_sponsored or
adm_nonsponsored, but neither of those is present in
FEATURE_NAMES_BY_TELEMETRY_TYPE -- only adm is.

To fix it, I added back the provider property to result payloads that I
previously removed, and I added BaseFeature.merinoProvider so each feature can
specify its Merino provider. Then, QuickSuggest can build a map from Merino
provider names to features, allowing us to look up features without needing to
hardcode something like FEATURE_NAMES_BY_TELEMETRY_TYPE or
FEATURE_NAMES_BY_MERINO_PROVIDER.

Since I added back the provider property, I had to update a lot of tests. (As
a follow up, it would be nice to centralize the creation of expected result
objects in the test helper.)

I also added BaseFeature.getSuggestionTelemetryType() to help implement the
score map and to better formalize the idea that telemetry types are an important
property that all quick suggest results should include.

https://hg.mozilla.org/mozilla-central/rev/904930f49d5a