* Merge server and client view state changes

* Up resource class used for Python 3.8 tests in CircleCI

* Ooops resource classs change should have be to the "cypress" flow

Our `mypy` task has been failing in CircleCI.

The issue is that `pipenv` is failing to deterministically resolve dependency versions, and is frequently resolving our `tornado=>=5.0, <6.0` dependency to Tornado 6 (because of other transitive dependencies on Tornado).

The solution is to use the `--sequential` flag in our `pipenv install` build step. From the pipenv docs:

> Installation is intended to be as deterministic as possible — use the --sequential flag to increase this, if experiencing issues.

So: pipenv installation is intended to be as deterministic as possible, but it's also possible to "increase its determinism" with a flag! (I think this is...madness.)

This PR *also* cleans up and documents a few things that I found confusing while tracking this down (with @jrhone's help!):

- The `mypy` cache is now stored in the project directory (and gitignored), rather than in `/tmp`
- We expire our CircleCI virtualenv cache key every day; I documented why we do this.
- Added docs to the "Create virtualenv" CircleCI build step.
- Removed the protobuf-caching step from the CircleCI jobs, because it's not actually doing anything.
- Updated the mypy ini to target Python 3.8, and fixed a new mypy warning.

…dropped that PR for this launch