Support multiple user id tokens per session

[bliptec]

1. The SDK doesn’t nicely handle setting tokens like this multiple times. In the 1DS fiddler inspector, I’m seeing a new ticket get added each time, so there’s a lot of 10001s in the tickets section. Over a long session this could grow unreasonably large, but looks like it should be a fairly easy issue to fix.

2. Using the AuthTokensController, the user_id token can only be set per http request instead of per-event (like user id normally can be set). This leads to at least a couple of problems:

   • The user token sent with the event isn’t completely deterministic. It’ll just be whatever the most recent user token was when that http request was formed, and an http request can easily include multiple events. Ideally, the user id token would be tied to the event.
   • The user token won’t be consistent with events persisted to offline storage. If there’s a period of no connection to OneCollector, a significant amount of events could be sent with the wrong, or even no, user id (no user id might happen if the events were saved in offline storage, there was a browser restart, and the old events get sent before another event with a user id token gets sent).

Currently Edge limits to events observed with the first user id token, but this isn't ideal for use-cases with multiple users signed in to different windows (ie. multiple personal accounts).

[maxgolov]

@bliptec - let's discuss this on a call next week. My current suggestion:

• Edge Data client may talk directly to LogManagerProvider: https://github.com/microsoft/cpp_client_telemetry/blob/aa674ea788f2c2b00270d091eb33966d8a230843/lib/include/public/LogManagerProvider.hpp#L22 creating a separate LogManager and ILogger per user identity. That will address the case when one process (one tab) has to deal with two different user identifies simultaneously. Both instances would point to different user data storage locations, separate pillars, never mixing data from different users in one storage nor in one batch.... With that concept you can have as many LogManagers per tab (one per user) as needed.

OR

• In case if one tab - one user profile - we can discuss how you can point LogManager to unique storage per user / per logged in profile. Such as two users logged in under different profiles would maintain their own telemetry storage and their own HTTP batches. You can correlate traffic from different tabs using SDK UUID (one per logged in Windows user) or Machine UUID (one per machine, for different users).

[maxgolov]

@bliptec - should we remove the Iron label for now? I don't think we are committed to this short-term, but we may tackle the proper long-term solution either end of this or early next semester. Alternatively I'd suggest we set the milestone on it to Iron - December, and see if we can get to that.

[bliptec]

Like we discussed at the community meeting, I'd prefer to leave it for Iron/December, with the understanding that it's fine if it doesn't happen in Iron. I just don't want to see it mixed with other unplanned work, since there was a privacy requirement to make sure this is properly supported in the upcoming future

[maxgolov]

Reforecast to [Ni] - added to the list for discussion with PM leads.