fix(device-id): device id drift between devtools products and altas cli COMPASS-10690

[alenakhineika]

Description

Initially, the .toUpperCase() modification was meant to apply only when using the legacy node-machine-id package, but the refactoring removed the isNodeMachineId flag and made it unconditional. This caused getDeviceId to use an uppercased machine ID as the HMAC key on all platforms, diverging from the Go denisbrodbeck/machineid library that Atlas CLI uses - which passes the raw ID directly. The Atlas CLI withAnonymousID calls straight into ProtectedID with no preprocessing - no uppercasing, no hashing before the HMAC. On Linux and Windows (where machine id is lowercase), this produces device ids that never match Atlas CLI, making cross-tool telemetry joins impossible on those platforms.

This PR removes .toUpperCase(), restoring the initial behavior with no case transformation, matching Go implenentation exactly. macOS is unaffected since machine id there is uppercase. Linux and Windows users will see a one-time device id rotation, but since cross-tool joining was already completely broken for them, there is no working join to preserve.

Open Questions

Checklist

• I have signed the Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)
• New tests and/or benchmarks are included
• Documentation is changed or added

[addaleax]

but since cross-tool joining was already completely broken for them

Why was that the case?

[alenakhineika]

There was no overlap in device IDs extracted from deftools metrics with Atlas CLI (see COMPASS-10690). Or you mean if to compare e.g. compass with vscode?

[addaleax]

Or you mean if to compare e.g. compass with vscode?

Yes, exactly – all DevTools products should still have had overlap with each other, no?

[alenakhineika]

After the fix ships, when users runs the new version of a DevTools product for the first time with a new device id, the analytics team could correlate that session with the last session using the old device id, for example by anonymousId. Then they can stitch the two ids together into a mapping table. But i messaged Natalia to confirm. Let's wait before merging. I'll post an update once I have answers.

[addaleax]

@alenakhineika Okay cool, thank you for checking with them – I hope this won't be a big disruption, I think somebody mentioned the idea of sending both IDs to be able to correlate for a while, but obviously it would be nice if we could avoid that