fix: send atlas uid as userId to compass telemetry COMPASS-7610

[paula-stacho]

https://jira.mongodb.org/browse/COMPASS-7610

Description

Main changes:

• upon successful atlas login, telemetryAtlasUserId is stored in the preferences
• this is then send under userId for telemetry calls (track and identify)
• directly after the user logges in with Atlas, an identify call is made
• identify call is only send if the userId = telemetryAtlasUserId is known

On Logging out:
When the user logs out, we don't clean up the telemetryAtlasUserId. this means subsequent identify calls might still be made and they will include the last known telemetryAtlasUserId. I discussed this with @gribnoysup and he explained such cleanup would be superfluous since the two ids (anonymous and auid) are anyway coupled in the records by then.

On tests:
I didn't find any existing telemetry unit or integration tests, and they're not simple/straightforward to add as it needs the CompassApp to init, so I skipped it for now.
Coming from jest, I had some trouble mocking the getTrackingUserInfo for the signIn test. In the end I found a way, but I must say I'm surprised that it's necessary to run sandbox.restore(); after the test suite. Without this, the getTrackingUserInfo was still affected even though it is now in a separate test suite. Is this normal or am I using Sinon in a wrong way?

As the e2e scenario for the first identify is now a combination of atlas login and telemetry, I had to make a choice on which suite should have it. The chosen way seemed leaner.
The subsequent run is more contained, so it's left in the logging suite. We just need to assume that telemetryAtlasUserId is already in the preferences (simulating that the user has signed in some previous run).

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added

Motivation and Context

• Bugfix
• New feature
• Dependency update
• Misc

Types of changes

• Backport Needed
• Patch (non-breaking change which fixes an issue)
• Minor (non-breaking change which adds functionality)
• Major (fix or feature that would cause existing functionality to change)

[lerouxb]

I'm not very familiar with this work so maybe I'm confused, but aren't we losing a test for the non-atlas-login case if you remove this?

[paula-stacho]

identify will no longer be called until we know the userId, this was requested by Ale (see the parent ticket https://jira.mongodb.org/browse/COMPASS-7519)

[lerouxb]

Won't we lose telemetry for all non-atlas users then? I clearly don't know how that stuff works 😆

[mcasimir]

@paula-stacho you are right the initial ask was to only identify in that case, but we cannot do that just yet, we would lose some of the attributes that we send via identify currently (although we should send them as regular attributes with events). We may need a follow up ticket to do that.

[paula-stacho]

ah I see! yes, we'd loose the "traits". there are no "traits" in segment track calls, and adding them to the properties would probably require changes in the processing.
I can bring back the "no userId" identify and it's e2e test, and create a follow up ticket. who owns the data in segment and post-processing? is it some other team?

[paula-stacho]

https://jira.mongodb.org/browse/COMPASS-7661

[lerouxb]

Looks good in as far as I understand what this code should be doing :)