feat: Add Workspace Switching feature

[einsteinx2]

Summary

• This adds the workspace switching feature allowing a customer to sign into a workspace, then later in the same app launch, switch to another workspace. It also handles the case where a customer signs into one workspace, the app is closed, then the app signs into a different workspace. In both cases, all event batches are attributed to the correct workspaces.

Testing Plan

• Was this tested locally? If not, explain why.
• E2E tested the implementation by connecting to a workspace, logging events, switching workspaces, logging another event and the uploading; also E2E tested by connecting to a workspace, logging events without upload, killing the app, connecting to a different workspace, and logging events.
• All existing tests pass and added new ones

Reference Issue (For mParticle employees only. Ignore if you are an outside contributor)

• Closes https://go.mparticle.com/work/SQDSDKS-6592

[Mansi-mParticle]

LGTM

[samdozor]

hi! I have more to review but found a hairy issue so wanted to give you feedback asap. will do another pass tomorrow.

[samdozor]

who is to say that instance didn't become null due to another thread in between 294 and 296?

i would:

• synchronize on the class (see getinstance) so nobody crazy can call this method simultaneously and
• grab a local reference to the instance, and then check if that's null and use that.

i'd lock on the instance (eg synchronized (MParticle.class)) and to be extra safe

[einsteinx2]

Lock added

[samdozor]

key factor in making threading work in the android SDK (and ios sdk for that matter..) is to make sure things run sequentially.

as you have it now - this will happen:

1a. customer calls mparticle.logEvent("foo")
1b async invoke message handler thread to store "foo"
2. then mparticle.switchWorkpace("bar")

and you'll prepare message uploads in (2) before (1b) ever gets around to even storing the "foo" event in the message table. actually you'll have this problem with the call to "endSession" above too since you're not waiting for that to store the resulting message.

so - you need to wait on the messages thread to make sure every event to this point has been stored before we prepare and delete etc.

but wait..there's more. the actual call to prepare should probably happen on the uploads thread, otherwise you'll end up with this method running simultaneously with natural/normal uploads and a mess of inconsistent/unpredictable state.

there's some precedence throughout the code base of doing things like this:

• MessageManager#doUpload() - which forces a message into the message handler and then into the upload handler just to make sure we do a full pass through both.
• IdentityApi which continuously uses mBackgroundHandler (which is actually the upload handler!) to ensure that identity requests are synchronous to uploads
• KitManagerImpl#runOnKitThread for another example of just using another thread

there's a few ways to code this but ultimately I think you need to accomplish:

• ensuring that everything currently queued on the message thread completes before you prepare this
• ensure that you don't concurrently modify the database/state/etc with both the message thread and upload thread

[einsteinx2]

Please see my latest commit, I believe it should address these concerns