WSGI undermines throttle limits

Alyx currently uses Django's default LocalMemCache and our WSGI settings set a maximum of 1000 requests per process:
https://github.com/cortex-lab/alyx/blob/4d8c5e2bddbc789db76b0cfcabb10d5b3f494aa9/deploy/app/docker/alyx-common.conf#L30

This means that the requests cache is lost every 1000 requests, effectively resetting everyone's request count. The more active the site, the less effective the throttling. Additionally adding processes to the WSGI will multiply the throttle limits.

A solution is to add another cache backend such as redis or DatabaseCache.

django.core.cache.backends.db.DatabaseCache persists between wsgi processes, however requires a createcachetable migration (this would have to be run every time a database is deployed afresh or built from an older backup). This would also add a SELECT on every request, plus an INSERT/UPDATE when the request is allowed. MAX_ENTRIES would have to be set well above the throttle values chosen for the site, otherwise it would be completely ineffective. The default is only 300.

redis is a local cache and would be much quicker, plus IP and request logs would not persist in the database backups. It would, however, require a new dependency and running service (could be a custom docker override). This would take up a small amount of disk space.

Another option is to raise maximum-requests. 1000 is considered aggressive for a Django app. Changing to 10,000 would cut the reset frequency by 10x but would allow for more memory growth over long-lived processes.

Start with deploy/app/docker/alyx-common.conf around line 30 and trace how Django request throttling uses the current cache backend. Compare the Redis, DatabaseCache, and maximum-requests options described in the issue, including deployment implications. Done means selecting and documenting one approach that preserves limits across WSGI processes and verifying the relevant deployment configuration.