Determine whether T399194: Implement different backends for anonymous and authenticated sessions is feasible. There are two questions to be considered:

• Do we always know in advance (before fetching data from the session store) whether we are loading an anonymous or a logged-in session? In the first approximation, the answer is yes - loading happens in SessionManager::loadSessionInfoFromStore() which takes a SessionInfo. But that SessionInfo can change based on the fetched data (we think we are loading an authenticated session, but the data is missing or invalid so we end up with an anonymous session instead) so need to make sure that happens in a manageable way.
• What happens when we are intentionally changing the authenticatedness of a session (logging the user in or out, or doing autologin)? Probably we are calling Session::resetId() in such cases and we just need to make sure that that method works fine with the new session abstraction; but maybe not.

The first stage the investigation will be just looking at the code. The second stage (after T399194: Implement different backends for anonymous and authenticated sessions is done) will be to deploy the new session store implementation, with the same backend used for anon and authenticated sessions, but some sort of logging to make sure that it would work correctly if we used different backends. Maybe that should be the part of T399195: Update logging and monitoring for multiple session storage backends.