[CORL-1048] Cookie Deprecation

[wyattjoh]

What does this PR do?

New third party cookie policies created by Safari in their recent 13.1 release have been causing issues for organizations using Coral with our non-SSO based (email/password) login methods.

This is closely related to the issue described privacycg/storage-access#2 (comment). Our hopes is that the Storage Access API takes these issues into account during the development to provide guidelines for first-party SaaS social integrations while maintaining the security boundary of the iframe.

Other comment platforms render directly into the DOM of the top level frame which provide inferior security boundaries when compared to the isolation granted by the iframe.

This PR removes cookies entirely as they are transparent to the JS and therefore causes issues described in the below scenario. This PR instead tries to save access token details to localStorage whenever possible to ensure admin logins persist after login.

Problem Scenario

1. The user first arrives at organization.com, where Coral is embedded from organization.coral.coralproject.net.
2. The user scrolls to the comment widget, clicks "Sign In" to open a popup, thereby granting temporary storage access.
3. The user signs in with valid credentials, and we set a cookie containing the access token.
4. We then send the access token back through postMessage to the iframe, and the user can proceed logged in.
5. The user refreshes or navigates on the top frame (on organization.com), and scrolls back to the comment section.

Because the user navigated, the storage access is removed, and the iframe no longer has storage access, and therefore does not show that the user is signed in. The issue we're experiencing now is when the user again clicks "Sign In":

1. A popup opens for login.
2. The popup (now granted storage access), sends a request to validate the current user session (where we now have the cookie attached).
3. The response says we're logged in via cookie, and the popup sends a message to the iframe regarding the valid credentials.

Because we don't have access to the access token after the refresh (because of the HttpOnly flag on the cookie), we can't send it back to the iframe after the second popup. This means that the user is stuck, the iframe does not have permission to access or send cookies along with the request, and we don't want to expose the cookie to the JS.

What changes to the GraphQL/Database Schema does this PR introduce?

None.

How do I test this PR?

Try to use in Safari where the Coral domain differs from the embedder domain.

[tessalt]

works!

[cvle]

Putting a merge block for now, needs discussion

[cvle]

Actionlist from discussion with @wyattjoh :

• Restore Relay Storage as source of truth
• Remove Auth, JWTManager, cleanupCallbacks and simplify into functions (or a class if it really needs to^^)
• clear session storage during clearSession
• No need to deal with about-to-expire-tokens for now
• Remove automatic pause/resume in createManagedSubscriptionClient

[cvle]

Just a question: What harm is there to output these errors in production?

[wyattjoh]

From a users perspective, it's not likely that this would be used to debug issues. If we're concerned about tracking these errors, we should consider these types of guards as indicators to include error reporters.