Dmitry to pick up after deployment on test.wiki

@Dbrant will work on this on behalf of both apps

I did some thorough testing of our branch of the Android app that "supports" temporary accounts, pointing it to testwiki, which is the single wiki on which temporary accounts is rolled our currently. Here are the findings:

All of the bullet points laid out in the task description are absolutely correct, and work as expected (when dealing with a single wiki).
To answer the open questions in the task description:

If we send that same cookie to another language wiki (that is participating in temporary accounts), will the same temporary account will be automatically created on that wiki and used?

This can only be verified when temp accounts is enabled on another wiki besides testwiki. Currently there are plans to enable temp accounts on test2wiki in the near future (T371116).

If the other wiki is not participating in temp accounts (language or wikidata), will the server will do nothing with that cookie, or will it instruct us to expire the cookie, or some other unexpected behaviour?

This is behaving as expected; if a wiki does not have temp accounts enabled, it ignores the temporary CentralAuth cookie, and does not invalidate it.

@Dbrant thanks for noting the results from Android. Were you able to explore iOS yet?

Here are some more detailed findings from a "regression test" of the current version, without any changes, of both Android and iOS apps, as they interact with the current rollout of temporary accounts on testwiki.

Android: The Android app has no issues that I can discern. An anonymous user is able to make edits (editing articles, talk pages, etc). From the point of view of the user, they are still "anonymous", even though, under the hood, they are operating under a temporary account, as dictated by the cookies provided by the server. If they proceed to make more edits, those edits will continue to be under the same temporary account, transparently to the user.

iOS: In the iOS app, the situation is a bit different. Shortly after making an edit, the app shows a screen that says "you've been logged out". This seems to be because the app believes that the user has just "logged in", and attempts to synchronize the user's reading lists. This is bound to fail, which causes the app to detect an inconsistency between its cookie state and its authentication manager state, which then makes the app believe the user has just "logged out", and clears the current cookies.

This seems to boil down to an architectural difference in how the apps determine if a user is "logged in":

• The Android app relies only on whether the current user has an entry in the Android AccountManager (our secure credential store). Notably, the app does not rely on the state of cookies to tell if the user is logged in, and instead leaves management/verification of cookies entirely to the network stack. This happens to allow the app to "handle" temporary accounts without any changes, since temp accounts operate purely at the level of cookies.

• The iOS app, on the other hand, relies on the state of cookies to tell if the user is logged in (e.g. in Session.isAuthenticated), and this dependency propagates to a few places where the app performs actions that are only intended for logged-in users, which leads to unexpected behavior in the case of temp accounts.

There may be a simple stopgap measure that can be applied for iOS:
In the Session.hasValidCentralAuthCookies() function, we could add a check for whether the centralauth_User cookie starts with the tilde character ~, which is the agreed-upon prefix for temporary accounts, and return false in this case. This way, the app will keep believing that the cookies are "invalid", even though they technically represent a temporary account, and will be passed to subsequent edits automatically. (But this requires further testing and investigation. Otherwise, a more wholesale refactor of the app's authentication verification logic will need to be made.)