Make API resilient to a Redis outage

[AetherUnbound]

Description

Presently, our API relies heavily on Redis and expects it to be highly available. This can be seen by performing the following:

1. just a (start the API)
2. docker stop openenverse-cache-1
3. Visit http://localhost:50270/v1/images/?q=cat

This high dependence on Redis makes it difficult for us to make changes to the cache, e.g. version upgrades like #3382.

We will need to build some resiliency into the API in every instance where one of the caches is used:

openverse/api/conf/settings/databases.py

Lines 47 to 59 in 3864283

	CACHES = {
	# Site cache writes to 'default'
	"default": _make_cache_config(0),
	# For rapidly changing stats that we don't want to hammer the database with
	"traffic_stats": _make_cache_config(1),
	# For ensuring consistency among multiple Django workers and servers.
	# Used by Redlock.
	"locks": _make_cache_config(2),
	# Used for tracking tallied figures that shouldn't expire and are indexed
	# with a timestamp range (for example, the key could a timestamp valid
	# for a given week), allowing historical data analysis.
	"tallies": _make_cache_config(3, TIMEOUT=None),
	}

In cases where we can continue without the cache (even at the detriment to performance), we should continue execution. If cache is absolutely required for a certain operation, we might issue an HTTP 424 for the request (though perhaps a 500 would make more sense?).

Additional context

This is part of the larger effort around upgrading Redis, see #3382

[sarayourfriend]

we might issue an HTTP 424 for the request (though perhaps a 500 would make more sense?).

I think 424 is the right option if we can handle it somehow. I think 5xx generally means "something unexpected went wrong and we don't know why"?