Closes: #8782

Description

Problem

User who was originally assigned treatment variation for a logged-out experimnent sees a different variation for the same experiment after logging out.

Reason for the change in assignment

1. User launches app -> ABTest variations for logged-out context experiments are fetched from the server and saved.
2. After login, due to Explat being reset, the locally saved experiments are deleted.
3. We load the experiments for logged-in context. Now, only logged-in experiments have a variation assigned.
4. User logs out from the Settings screen.
   1. Due to change in state, AppCoordinator navigates to the login screen here.
   2. This navigation to the login screen happens even before this line from Settings is executed.
   3. The navigation also happens before analytics (i.e. ABTest) is reloaded here.
5. When the login screen is displayed, no variation value is assigned for the logged-out experiment, and by default, the control variant is shown to the user.

My fix in this PR

We fetched the variations for only specific contexts (logged in/out) when analytics is reset. I changed that behaviour and instead started fetching the variations for all available experiments.

• The idea is to load the variations for all experiments irrespective of whether the user is logged in or not.
• As an anonymous ID is assigned to requests sent in both logged in/out state here, we are receiving the correct variation for logged out experiments even if the user is logged in/
• I believe the backend can use the provided anonID and auth token values to identify the device and user and provide correct variation values.

To verify this change works as expected

• @selanthiraiyan to add logged-in and logged-out A/A tests to verify the behaviour and check for crossovers.

A better solution (Not in this PR)

Wait for the ABTest variations to reload and proceed.

• Make WooAnalytics.refreshUserData() async and wait for it to finish from everywhere we call the method.
• Stop navigating to the login screen from AppCoordinator. (I am not sure how and the impact of this change)
• We will have to revisit the sequence of changes done in DefaultStoresManager.deauthenticate() method. The order of the execution matters. For example, the state is being set to DeauthenticatedState even before we clear/reset other things.
• WooAnalytics.refreshUserData() method is currently called from
  • Upon switching store in SwitchStoreUseCase.finalizeStoreSelection() and upon switching store in DefaultStoresManager.removeDefaultStore(). I hope one of these calls can be avoided.
  • Upon deauthentication from DefaultStoresManager.deauthenticate()
  • Upon synchronizeAccount from DefaultStoresManager.synchronizeAccount()
• As this solution requires changes to several critical areas, I opted for the other solution for now.

Testing instructions

• Install and launch the app. Logout if needed.
• Launch and skip onboarding.
• If you don't see the "Continue With WordPress.com" button to login you have been assigned treatment variation for the woocommerceios_login_rest_api_project_202301_v2 experiment and you can test this PR (If not you need to use a sandbox to for a variation. You can follow the instructions from this PR to assign a varition to your device.)
• Login into the app using site creds.
• Go to settings and logout.
• You will be navigated to the login screen and ensure that you still don't see "Continue With WordPress.com" button. i.e. You are still assigned the treatment variation.

Screenshots

NA

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.