fix metametrics option tracking

[brad-decker]

in #9222, which aimed at removing negated conditions, we accidentally introduced a change in how we filtered events from firing on the metrics opt-in page.

Previously, we checked if the previous value for participateInMetaMetrics was not equal to what we were tracking. e.g: if the user was opting in, we made sure the previous participateInMetaMetrics was not true. The change made it such that it would only track an event if the previous participateInMetaMetrics was strictly the inverse of the user's intention. e.g: if the user was opting in, we made sure the previous participateInMetaMetrics was false.

The problem here is that all new users default this value to null, which would have been fine in the previous version but not find in the new version.

This issue landed in 8.1.0 on Oct 13, and subsequently, 8.1.3 which migrated us off of matomo landed on oct 28. Due to chrome review times and what not, there probably wasn't a huge gap between when the bug was rolled out to most of our chrome users and when matomo was removed for most of our chrome users.

[metamaskbot]

Builds ready [52afb4f]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• code coverage: Report
• dep viz: background
• all artifacts

Page Load Metrics (539 ± 21 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	30	58	45	8	4
		domContentLoaded	492	682	538	44	21
		load	494	684	539	44	21
		domInteractive	492	682	537	44	21

[Gudahtt]

LGTM, great catch!