Add caching to diff server #242

The diff server should support a caching mechanism for:

1. The HTTP responses bodies gathered for the a and b parameters to every diff:

   web-monitoring-diff/web_monitoring_diff/server/server.py

   Lines 311 to 328 in 8e0c499

   	query_params = self.decode_query_params()
   	# The logic here is a bit tortured in order to allow one or both URLs
   	# to be local files, while still optimizing the common case of two
   	# remote URLs that we want to fetch in parallel.
   	try:
   	urls = {param: query_params.pop(param) for param in ('a', 'b')}
   	except KeyError:
   	raise PublicError(400,
   	'Malformed request. You must provide a URL '
   	'as the value for both `a` and `b` query '
   	'parameters.')
   	# TODO: Add caching of fetched URIs.
   	requests = [self.fetch_diffable_content(url,
   	query_params.pop(f'{param}_hash', None),
   	query_params)
   	for param, url in urls.items()]
   	content = await asyncio.gather(*requests)

   These are most valuable to cache, since the server frequently sees repeated calls for the same a or b URLs when users are switching between diff types, or comparing successive changes (e.g. comparing capture X to capture Y, then capture X to capture Z).

2. The results of a diff. This is less critical, since a proxy server can also do this caching (as we do in our own deployment of this). But nice to have so you don’t need that proxy server.

I think the most straightforward thing for now is to do the caching with Redis. It’s reliable, common, and relatively easy to deploy. When using Redis, hiredis is really great to use if possible; in my experience it makes a big performance difference (we use the Ruby bindings in web-monitoring-db).

The cache should be optional, or maybe fall back to an in-memory cache if Redis is not configured.

@vbanos over at Internet Archive suggested using dogpile.cache, which looks like a standardized interface to a variety of different pluggable cache backends. It has a Redis backend built-in. I haven’t used it before, but looks good and is part of the sqlalchemy family, so seems like a great place to start.

This is related to, but not a core part of, addressing the stability issues we’re experiencing from a flood of bad captures over at the Internet Archive (edgi-govdata-archiving/web-monitoring#192)