disk cache: verify CAS digests fetched from a proxy backend

[martinpitt]

Previously, blobs fetched from a proxy backend were committed after only a size comparison. A backend answering with same-length wrong bytes got them stored under the digest they were asked for, and served to every client after that.

Verify proxy reads by -hashing their blobs and comparing before committing. A hash mismatch is logged, dropped and reported as a cache miss, similar to a size mismatch.

Client uploads already are verified that way, so this closes the verification gap for proxy mode.

---

I'm trying to set up two bazel-remote instances chained over the HTTP protocol, as in #524: a developer-side instance with
--http_proxy.url pointing at a shared one, --num_uploaders 0 so it never writes back. The shared instance is published read-only by a reverse proxy restricted to GET and HEAD (which makes it read-only). A mistake there lets anyone PUT, and with no digest check on the fetch side nothing downstream would notice.

Related:

• discussion: should we verify the hash in the CAS? #32 asked whether CAS hashes should be verified at all and concluded in favour. This extends that to the one write path left out.
• disk cache: store a data integrity header for non-CAS blobs #186 does the same job for AC and raw blobs, which this PR deliberately does not touch.
• ExtractLogicalSize returns abnormal size for s3 file #666, Failed to fetch blobs because they do not exist remotely #870: proxy backends and cache directories in the field do return data bazel-remote did not write.