Remove Google data after user revokes access

[tyler-dane]

Problem: Compass treats a user as authenticated after revoking Google access
Solution: Ensure Compass can always differentiate between a user who has an active GCal connection and one who doesn't. For those who don't allow them to still use the app, but remove their old GCal data.

Expected Behavior

Handling 410 errors

Immediate handling

• After a user disconnects their account from Compass, and they make a change in GCal, the Google webhook will notify us about the change
• Compass will try to fetch the changes, but will receive a 410 error (working)
• Compass will delete the user's data as a result (working)
• User goes back to Compass window
• User's localStorage compass.auth shows:

{
    "isGoogleAuthenticated": true
}

• User old events should not show (they're still showing)
• Instead, the demo data should be showing, as if the user never had a Compass account

After revoking

• After revoking access to Google, the user's Compass data should still be visible (the events/tasks with origin: "compass"). If a user wants to remove that data, they'll have the option to do that through Compass in a future PR.
• The user should be able to go to any view (they're currently redirected to /day and shown the toast)
• The toast should

Planning

Priorities:

• Simplicity of implementation and maintenance. No complex or unconventional solutions
• Minimal requests. Don't overload the backend or make the client excessively noisey

Start by answering these questions:

• After the backend receives the 410 error from google, it should notify the client over websocket if connected (not sure if this is happening now or not)
• If the client is not connected, we need a way to determine if the client is no longer connected. How should we do this, while minimizing how many calls we need to make to the backend / websocket server? We don't want to continually poll. A regular heartbeat service is acceptable with sane intervals.
• How to handle isGoogleAuthenticated local storage value? Should we remove that in place of the heartbeat service?

Current Behavior

No response

Steps to Reproduce

No response

Possible Solution

No response

Context

Related to #1478