Reduce gunicorn worker count for LMS/CMS
Reduce gunicorn worker count for LMS/CMS

We have been experiencing issues in production with memory (over-)utilization.
While we are restarting the gunicorn workers every `n` requests (see:
`EDXAPP_MAX_REQUESTS`), this seems insufficent.

We also increased the instance size, hoping that more memory would help.
As it turns out, the `*_gunicorn.py` files dynamically scale the worker
count based on the number of available CPU cores. So when we increased
the machine size and the CPU core count increased, so did the number of
concurrent worker processes (and subsequently RAM usage even idling).

Despite the occasional spike, we generally see worker processes using
up to a gig of RAM each (2-3% of the 30gig total); they don't appear to
grow much larger before being cycled/restarted.

Given those assumptions, we were all but guaranteed to always be using
nearly all memory at any given time. By reducing the total worker count,
this should hopefully bring us into a safe range.

Stanford-Online/configuration,Stanford-Online/configuration,Stanford-Online/configuration,Stanford-Online/configuration,Stanford-Online/configuration