Bug 2003370 - Use and react to Gecko preferences stored values

[ohall-m]

This patch adds functionality to use the new PreviousGeckoPrefState.

It adds:

• set_gecko_prefs_original_values for external handling of setting prefs back to original values
• Mechanisms to return to a previous states when:
  • on_experiment_updated
    • Certain situations and as determined in will_pref_experiment_change
  • on_experiment_ended
  • on_opt_out
  • unenroll_for_gecko_pref

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

[ohall-m]

Hey @freshstrangemusic and @jeddai, just leaving a message that part 2 to use the stored values is up because I can't set reviewers!

The observer part 3 will be in bug 2006095.

[ohall-m]

I didn't add anything in unenroll_for_gecko_pref because this is what the observer will call into in the event of an external gecko pref change and we do not want to revert the pref in that case. Mentioning it as a heads up because I think it might be a bit unexpected from certain standpoints - like it almost looks like a utility that handles all the pref stuff in one swoop. I keep revisiting it and am afraid it could be confusing down the road.

[freshstrangemusic]

I didn't add anything in unenroll_for_gecko_pref because this is what the observer will call into in the event of an external gecko pref change and we do not want to revert the pref in that case. Mentioning it as a heads up because I think it might be a bit unexpected from certain standpoints - like it almost looks like a utility that handles all the pref stuff in one swoop. I keep revisiting it and am afraid it could be confusing down the road.

The gecko side has to handle the pref resetting. Because we're unenrolling we get to throw out all of our state regarding those prefs and original values.

[freshstrangemusic]

I didn't add anything in unenroll_for_gecko_pref because this is what the observer will call into in the event of an external gecko pref change and we do not want to revert the pref in that case. Mentioning it as a heads up because I think it might be a bit unexpected from certain standpoints - like it almost looks like a utility that handles all the pref stuff in one swoop. I keep revisiting it and am afraid it could be confusing down the road.

The gecko side has to handle the pref resetting. Because we're unenrolling we get to throw out all of our state regarding those prefs and original values.

Actually, I think we need to tell Gecko to restore all the prefs except the one that changed. I keep forgetting which sides have what responsibilities.

[ohall-m]

Actually, I think we need to tell Gecko to restore all the prefs except the one that changed. I keep forgetting which sides have what responsibilities.

Updated, thanks!

Round 1 comments should now be addressed on this revision