[WIP] Passwordless email and local dev server

[lazerwalker]

This does two main things:

1. Rips out Firebase and replaces it with a "magic email" implementation. The /sendMagicEmail endpoint takes an email address, generates a URL that has query params containing a unique userId for that email address and an expiring auth token based on that userId, and sends that URL to that email address. The client stores such query params in localStorage and sends them along as headers with network requests. The server now validates that token instead of the previously-used Firebase token. When running as a local dev server, it doesn't send emails but logs URLs to the console. See docs/authentication.md for more information.
2. Provides an alternate server implementation, server/server.ts, which is an Express server that serves the same routes as our Azure Functions server, as well as WebSockets (including a reimplementation of Azure PubSub's group management functionality). This implementation is explicitly not production-ready, and is currently only intended to be used for local dev, although this may change. npm run dev now runs both client and server instances, with separate individual npm run dev:client and npm run dev:server commands also existing. See README for setup info.

I tried to keep refactors minimal to minimize the footprint of these changes, but a few incidental refactors to note

• npm run dev performs an initial copying of all images into the dist folder, meaning that you won't have broken images in dev instances any more. This does not auto-update, so if you add new images you'll need to re-run the dev server.
• The login code path in App.tsx is much simpler now, including cleaning up the muddled Authenticate reducer action.
• The Admin page no longer has the ability to log in. Just log into the main app and then go to the admin page. This is mostly laziness (it would require adding a config flag to /sendMagicEmail to allow sending an alternate landing page in the URL), but I think it's fine and good to reduce that complexity / code duplication.
• Removes the /cognitiveServicesKey endpoint, which existed to set up live transcription from Twilio video and was not being called from the current client

These changes require Node 18 on the server, where (as of 9/19/2024) we are currently using Node 14 in production (which is EOL). Before we deploy this, we should migrate our existing live production server to use Node 18 (an Azure Portal change, does not require a code change/deploy) and confirm this does not cause any issues. This should be uncontroversial (famous last words).

Work that needs to be done:

• Add an Azure Communication Services implementation to actually send magic emails (https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/send-email?tabs=windows%2Cconnection-string%2Csend-email-and-get-status-async%2Csync-client&pivots=programming-language-javascript)
• Write a one-time script that, for all Firebase Google and email users, creates a userId mapping from their email to their old userId, so they can log in as their old account with passwordless email (use the CLI to get an export: https://firebase.google.com/docs/cli/auth#authexport. For each account with an email, write to our Redis mapping with that email and their old userId)
• (nice-to-have) Write a web tool where a mod can enter a Twitter handle and email address to create a userId mapping
• (nice-to-have) The client auth path used to have a browser resize event handler that was apparently only used for modifying how we render Twilio video squares. It's been moved out of the auth flow, but still runs. I'd like to try removing it and confirm that nothing bad happens
• (nice-to-have) Update ARM template to include ACS and Azure PubSub
• (nice-to-have) Set up npm run dev to watch the image folder and recopy as necessary (should just require changing how we're using rsync)
• Harden PubSub auth (this is likely also a security vulnerability of our current system, so ask me elsewhere for details)

I think it is unlikely we want to deploy this for 2024 (unless we have a good answer to "how are we going to sufficiently test a new authentication flow"), but that can be a discussion topic once this is more ready-to-go.