I just discovered that there might be a problem with these changes or with the original solution suggested here: https://phab.comm.dev/D5875#inline-39619.

Let's assume that for some technical reason client (web or native) can not establish a socket connection and we do not share any data on login due to not accepted policies.

After accepting the terms, the data will not be fetched and the user will see an empty app (no socket connection which was responsible for delivering this). On web, there is no such problem, because refreshing the page will cause web-responder to deliver all the data.
Worse case is native, when previously without a socket connection, user had data from login response and could e.g. send a message via HTTP. Now will see the empty app and the only fix is to log out from the app and log in again (terms were accepted so there is no need to do it again and all data will be in the login response).

This leads to questions:

1. Is it possible that there will be no socket connection and is it frequent?
2. This is really a corner case, when user logs in after a time, has not accepted terms and no socket connection, and uses native, should we look for a fix, like eg. fetching this data via HTTP?

While I don't think socket failures should be common, one place we've observed it is when there is a lot of data to transfer for the socket initialization, and the user is on a bad connection: ENG-1934

While we have a 60s timeout for log-in, we only have a 10s timeout for socket transfers. The long-term solution for this is ENG-1945, but we haven't been able to prioritize it recently.

In the past we've had several other "socket crash loops" (when we are unable to create a socket connection with the client). Some potential solutions here:

1. Prioritize ENG-1945. Would probably take ~1-2 people-weeks of work
2. Add some code to lib/socket/socket.react.js that will try to call fetchNewCookieFromNativeCredentials to log the user in again if the socket fails to connect several times in a row. However, this will only work for username / password users... SIWE users would need to go through the SIWE auth flow again, and we can't do that invisibly for them in the background. Would probably take ~3 people-days of work, but only helps username / password users
3. Force log out the user in the specific case where (a) they just had their login invalidated due to a policy issue, and (b) after accepting the policies, the socket is unable to connect several times in a row. Would probably take ~2 people-days of work
4. Don't worry about this... the DISCONNECTED bar will appear, and maybe the fact that it doesn't disappear will prompt the user to log out / log in or delete / reinstall app. Not great, but potentially okay to unblock this work. Would take 0 work

Arguably doing 2 and 3 together would be less work than the sum (~5 people-days) because some of the work would be repeated. Maybe we can scope the solution like this:

1. Track socket crash loops. We would track the number of consecutive socket connection failures when there is no connectivity issue (see connectivity in Redux and ConnectivityUpdater)
2. Track the scenario where we have a lot of data to download from the server. We can probably use serverTime: 0 as a proxy for this, eg. if updatesCurrentAsOf in Redux is 0
3. If the user is a username / password user, then when we detect this scenario (socket crash loop + updatesCurrentAsOf === 0), we trigger fetchNewCookieFromNativeCredentials (as is already done in lib/socket/socket.react.js)
4. If the user is a SIWE user, we simply force log them out and display an Alert saying something like "After acknowledging the policies, we need you to log in to your account again"

I think this ~3-4 people-days.