pip_audit, test: generalize caching middleware

[woodruffw]

This makes our OSV adaptor use the same caching middleware as our PyPI adaptor. Notably it does not currently improve performance, since OSV doesn't appear to be sending ETags or other caching headers with its response:

content-type: application/json
grpc-accept-encoding: identity,deflate,gzip
accept-encoding: identity,gzip
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
grpc-status: 0
grpc-message:
x-envoy-decorator-operation: ingress QueryAffected
x-cloud-trace-context: 0fce3535ef964b43794e46a0431db0f1
date: Mon, 06 Dec 2021 16:18:56 GMT
server: Google Frontend
content-length: 1197

That being said, I think we should still merge it -- it'll be handy for #187 as well, and it will improve our performance on OSV if/when ETags are added.

Closes #179.

[di]

Notably it does not currently improve performance, since OSV doesn't appear to be sending ETags or other caching headers with its response

Given that the OSV API uses POST requests, we might never get ETags there. I created google/osv.dev#274 to determine what the right way to cache OSV should be. In the meantime, we should move forward with this regardless.