Beta branch

This was discussed on zoom with @MendyBerger and @corinnewo , and agreed as a good idea to implement in the future.

Currently we have these branches:

1. sandbox: latest changes. is allowed to break at any time. database may be wiped. The name reflects the intent, it's a safe "sandbox" for pushing any code and not having to worry that it breaks for users. Theoretically this branch and all its assets could be deleted and end-users won't be affected at all.
2. master: stable user-facing releases. ideally it should never break. All the data here is live and in-use. This includes third-party services like Algolia. The name is for historical reasons, the intent is "release"

Pushes and merges have been entirely up to the whim of developers, with no real scheduling with QA

While we are in pre-release mode and have no users, this is absolutely fine, testing for features and bugs can be done on the master branch for example.

However, once we are live we can't really do that. Pushes to master should happen after QA and only when CI passes for both frontend and backend.

This means all testing must be done against sandbox only... which poses a problem since it means developers can't break sandbox if it's being used for focus groups, demos, user-testing, etc.

Therefore we agreed on the following changes:

1. We need a new branch hooked into the CI called "beta" (or "staging", "pre-release", whatever). This would function like a feeder into master and must also not break. It should use the same database and algolia etc. as master.
2. Scheduling:
   1. Sandbox: stays as- devs push whenever, stuff can break
   2. Beta: always merged from sandbox. Requires all CI to pass and project manager to green-light (but doesn't have a strict user-testing QA requirement, this branch is used for user-testing)
   3. Master: always merged from beta. Requires project manager to green-light after thorough QA