fix(3932): Fix User traits changed during onboarding are never sent to Segment

[DDDDDanica]

Description

User traits are not logged during onboarding (including the initial values, and any changes made during onboarding).
After following the steps https://github.com/MetaMask/MetaMask-planning/issues/3932#issuecomment-2604742483, The data changes are as follows:

• initialize the extension with default state
  {participateInMetaMetrics : null, dataCollectionForMarketing: null}
• during onboarding, when we change participateInMetaMetrics to false by clicking "No thanks", and state is {participateInMetaMetrics : false, dataCollectionForMarketing: null}
• after onboarding, user navigates to privacy settings, and toggle on "Participate in MetaMetrics", state is {participateInMetaMetrics : true, dataCollectionForMarketing: null}

=> the state of dataCollectionForMarketing is not changed from this action, hence the batch request will not include unchanged value dataCollectionForMarketing, which means has_marketing_consent is not going to be included in first identify call to segment.

Hence the solution is to modify the value of dataCollectionForMarketing to false in the state and the difference of state will be picked up and included in traits sent to segment in identify call.

You can find some e2e tests covering the situation in test/e2e/tests/metrics/segment-user-traits.spec.ts

Related issues

Fixes: https://github.com/MetaMask/MetaMask-planning/issues/3932

Manual testing steps

• Install the MetaMask extension
• Must use production build, or build with SEGMENT_WRITE_KEY and SEGMENT_HOST set
• See here for more information on how to set these in a dev build: https://github.com/MetaMask/metamask-extension/tree/main/development#debugging-with-the-mock-segment-api
• Open dev tools for the background process (background.html / service worker)
• In the dev tools networks tab, filter for Segment requests
• For a production build, filter to segment. For a dev build, filter to whatever you set for SEGMENT_HOST
• Proceed through onboarding, opting out of metametrics and marketing data consent
• After onboarding, go to privacy settings and enable "Participate in metametrics"
• You should see a request with type: "identify" to Segment, it comes with traits of {has_marketing_consent : true, is_metrics_opted_in: false}

Screenshots/Recordings

Before

After

https://www.loom.com/share/9375153003c44231a65a685305ec1828?sid=c58f98f0-6fba-400f-8f96-8e53c316879f

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[Gudahtt]

Effectively this is working around the underlying bug, which is that initial values for traits (and modifications to traits while metrics are disabled) are never sent to Segment. Why not solve the underlying problem? The issue still affects every other trait.

This also fails to meet a design goal in the implementation of this work, which is to ensure the user has been prompted to make a decision about the marketing consent toggle one way or the other. null represents the state where they haven't made a decision. If we overwrite it with false, it may result in some users not getting the prompt (e.g. for an existing user, if they enable metrics in settings).

[DDDDDanica]

This PR will provide the solution to fix the issue from the root instead of only covering one case
#29871