Notifications when seats open up

[ryanhugh]

PR to keep track of the progress of #10. Made a bunch of different changes to a bunch of files for this feature. Still have a good chunk of work to do before this is done.

What is done so far:

• Decided to use Firebase to keep track of the user data. We aren't storing that much data in Firebase at all and should be far below their free tier limit.
• Notifications are sent to people via Facebook Messenger. We were approved for pages_messaging and pages_messaging_subscriptions and can send people messages months after their last interaction with our FB bot.

The new updater.js file runs every couple of minutes, pulls in the user data, checks for changes to the classes people are watching, and notifies people accordingly.

Some details about how the authentication is going to work below. Going to write out documentation about how all this works.

TODO/How we could expand this feature in the future:

• Lets ask the user to sign into Facebook if they click the first button and are not signed in. (The Send To Messenger button doesn't even render if they aren't signed in lol).
• Download the user's data from the backend to the frontend and show them which classes they are watching
  • We could add another column to desktop class panel when that class is being watched that has a toggle so people can enable and disable watching sections individually
  • More tests, comments & clean up the code

(also I need to fix up sectionWasentWatchingBefore stuff)

[ryanhugh]

One of the interesting pieces of this PR is the authentication for future access to your data in the DB. There are two different parts of code where we would need to access a specific user's data in the backend: when the user sends our FB bot a message (webhook endpoint) and when the frontend wants to access the data. When we receive a webhook from Facebook on a user's behalf, it will include the sender id of the user and the webhook itself will be signed by Facebook. This lets us know for a fact that it is coming on behalf of that user.

However, in the frontend, we need more than just a sender id to verify that the request is coming from that user's behalf. I added some code so frontend will generate a long random string (loginKey) that we can pass to the backend and then later use to verify that this frontend is logged in as a specific user.

We can add this loginkey to a ref param in the Sent To Messenger button, and, when the button is clicked, it first be send to Facebook's servers, and then, from Facebook, to our backend to be saved with the rest of the user data in firebase.

Send To Messenger Docs: https://developers.facebook.com/docs/messenger-platform/discovery/send-to-messenger-plugin

After this initial button is clicked, we can have the frontend use the login key to request the sender id of the current user from the backend. This sender id would then be stored in the frontend in local storage next to the loginkey. I looked into ways to fetch the sender ID from the frontend straight from Facebook's servers but it dosen't look like it is possible to do this. Here are the pieces of info you can fetch from the frontend after the user has clicked the Send To Messenger button: https://developers.facebook.com/docs/messenger-platform/identity/user-profile

It is also possible to get some more info in the backend with the data that Facebook provides from the webhook.

After that, the frontend can send the loginkey and the sender id to the backend to fetch info about this user. The webhooks are also secure because each request is signed by facebook.

[ryanhugh]

For now, I am just going to get the generation of the loginkey in place, so we can, sometime in the future, add endpoints that actually fetch the data with a valid loginkey and show which classes the user is watching in the frontend. I am thinking we should push this feature to prod with some basic functionality, and then we can come back and make it better.