It was found during T335425 that:
* background processes relating to reading list syncing were receiving 401 errors and automatically logging the user out.
* temporary accounts were not being recognised by the app as being logged in
* app does not attempt to fetch notifications
**Tasks**
[] Update iOS authentication management to support temporary accounts
[] Audit app functionality in relation to temporary accounts, testing via test.wikimedia.org
[] Engineering only fixes to features to support or at minimum fail gracefully when handling temp account authentication
**Engineering Details**
1. Clone cookies after edit posts
I do **not** expect our newer networking stack calls (WMFBasicService) to return any responses with the cookie set. As of today those calls are fundraising config calls, Apple Pay payment calls, and fetching the article summary. No MediaWiki editing calls go through here. So WMFData and by extension WMFBasicService can be left untouched.
What that does mean is that we need to make some changes to the legacy networking class in Fetcher.swift. For any POST calls there, in the response completion block we need to call `self.session.cloneCentralAuthCookies()`, that way any new cookies that spin up from an edit POST are propagated to the other wiki domains.
2. (Cleanup) Remove Session.isAuthenticated
Session should not care about "authenticated" states, instead it should only be aware of cookies (if there are valid ones, to clone cookies, or to remove cookies). WMFAuthenticationManager should be the only class that modifies and is aware of an "authenticated" state.
3. Add convenience isTemporaryAccount public Boolean property to WMFAuthenticationManager
Check WMFAuthenticationManager's `loggedInUsername` format and set to true if temporary account username pattern matches.
4. Audit related calls throughout the app and consider if action should be taken if `isTemporaryAccount` = true. If **not**, wrap up logic in a (if !authenticationManager.isTemporaryAccount) conditional.
`getLoggedInUser` completions
`getLoggedInUserCache` calls
`loggedInUsername` calls
`isLoggedIn` calls
This is hopefully enough to patch up the underlying bugs.
Additional things to test:
When in a temporary account state, terminate the app then relaunch. The app attempts to login the user again when relaunched, and it's unclear what will happen here. Do an edit, is the temporary account retained?
Test editing on pilot and non-pilot wikis. We want to be sure any of our cleanup methods (`resetLocalUserLoginSettings`, `session.removeAllCookies()`) do not clear out pilot wiki cookies as we edit back and forth.
**Next level cleanup:**
There are several methods and states that reference a "logged in" user. Upon first glance these appear to be users that fetched the MediaWiki API userinfo API (which returns the authenticated user info). It seems likely temporary accounts will have a valid userinfo response from that API. We should rename these methods to reflect this is nonIP users, perhaps, since now these methods could reference both logged in users AND temporary account users.
Add a very clear enum of state in WMFAuthenticationManager, instead of "isLoggedIn" & "isTemporaryAccount":
```
WMFAuthenticationManager {
enum LoginState {
.ip
.temp
.permanent
}
let var loginState: LoginState?
```