Changes request patterns and response handling to match Go backend.

[krashanoff]

Updates the frontend's backend request pattern to match our Go backend's.

• Favors HTTP response status instead of the "ok" field (eliminates use of ok field in backend responses).
• Uses HTTP methods for idiomatic requests (e.g., use GET for getting your user data, and PUT for putting new user data in the database)
• Adds the userCreate function to fetch.js (see here).
• Inherits a very strange antiquity from the JS backend (see below).

getUserData

This is the weird thing. The JS backend, believe it or not, never had a createUser endpoint. Instead, it just made a call to getUserData and then the getUserData endpoint would create the user document if it didn't exist??? You can check out the source code for yourself. This is real.

There's a lot to unpack there, so let's dive in.

Why?

Well, if you take a peek at our user creation flow, specifically on line 111, you'll see that we make a direct call to Firebase to create the user.

Is this wise? Kind of. It lets us get away with user creation without having to deal with hashing and storing it ourselves. The downside, though, is that we now have a promise-chained form submission that touches the database directly. I tried splicing a direct call to the user/create endpoint on the new backend in there (say, in the then after the call to firebase), but to no avail.

(less-than-ideal) Solution, Risks & Trade-offs

So how do we solve this problem? The fix I used was a rather dicey maneuver: replicate the JS backend's behavior, but on the frontend. That is, if someone has a cookie for an account that doesn't exist, and makes a call to getUserData, then on failure the function will try to make a call to createUser before recursively calling itself. This is """"technically"""" safe, since createUser will fail if the backend is down, and succeed if the user already exists, but we can hypothetically get into an infinite recursion situation in the perfect storm.

I personally don't like that, and would like to eliminate this artifact, but I think that at this point we've been sitting on this PR for 6 months. It's "view-only" (#219) round two. It's time for it to get merged and handle the issue in another one.

---

This PR supersedes #235, and will hopefully - in time - archive uclaacm/TeachLAJSBackend. It will warrant a major semver bump, and deprecation of the TeachLAJSBackend. Prior to merge, the production Go backend will be deployed on Heroku.

[krashanoff]

Lord forgive me, work on this branch was getting so stale that I just went and redid it for a third time. It actually works now though. Unblocked.

[willob99]

Looks good to me!