fix(rum-legacy): send user and account identifiers as strings

[Fiona2016]

Problem

The intake decodes usr.id, usr.name, usr.email, account.id and account.name as strings and rejects the whole event when one of them is a number.

The modern bundle converts these fields with String() before attaching them (ensureProperties in packages/core/src/domain/context/contextManager.ts). The legacy bundle stored them as given. A page that calls setUser({ id: 12345 }) therefore reports normally from modern browsers but loses every event from IE9-11.

Change

setUser, setUserProperty, setAccount and setAccountProperty in packages/rum-legacy now convert the same fields the same way:

• Empty values (undefined, null, '') are left alone, as in the modern bundle, rather than sent as "null".
• Custom fields keep their type.

Verification

• Four new specs in publicApi.spec.ts. Three of them failed before the change (numbers went out as numbers) and pass after it. The empty-value spec passed both before and after.
• yarn test:unit: 3193 passed.
• packages/rum-legacy: yarn build:bundle passes the ES5 parse, missing-API, reserved-word and legacy runtime checks.
• Typecheck, lint and prettier are clean on the changed files.

[flashduty]

Reviewed as part of this week's SDK/component-library review.

The coercion itself matches the modern bundle: ensureProperties in packages/core/src/domain/context/contextManager.ts (type: 'string', via userContext.ts / accountContext.ts propertiesConfig) converts the same five fields and also leaves undefined / null / '' alone. So the parity claim holds, and the negative control (3 of 4 specs failing before) is convincing.

One gap, documentation/contract only, not blocking:

The coercion also changes what the getters return. getUser() and getAccount() are shallowMerge(userContext, {}) over the very context these four setters rewrite (packages/rum-legacy/src/boot/publicApi.ts:326 and :341), so setUser({ id: 42 }) followed by getUser().id now yields '42', not 42 — on every browser, not only IE. The v0.3.2 CHANGELOG entry describes only what goes out on the wire, and none of the four new specs asserts the getter.

A page that pins the old type breaks silently after upgrading: if (getUser().id === currentUserId), a numeric id used as a Map/object key, or arithmetic on account.id. Since getUser() is public API on the legacy bundle, that is the one part of this change an integrator can observe without looking at the intake.

Suggestion, both cheap:

• one clause in the v0.3.2 entry ("getUser() / getAccount() now return these fields as strings too"), and
• one spec pinning it, e.g. api.setUser({ id: 42 }); expect(api.getUser()).toEqual({ id: '42' }).

Filed as a comment rather than a PR: I could not run yarn test:unit from this review session, so I did not want to add an unverified spec.