Improve director's existence checks

[bbockelm]

In #1575, I took the first swing at making the object existence checks scalable / usable.

I think there's still work left to be done:

1. The errgroup should be replace with a coordinator goroutine that pulls requests from a channel and decides whether to make them. Currently, if 10 concurrent clients all request the same object, on a cache miss there will be 10 requests out to the origin. We could have the intermediate goroutine catch and forward only one request at a time.
2. The concurrency (# of pending requests to a given origin) should be configurable.
3. If we get a 403, we should check to see if the token should be valid and log accordingly.
4. We currently blindly retry failures to see if the checksum request was causing problems. We shouldn't do this for every request (as it doubles our total request count to the remote service) but sample periodically whether checksums are supported.
5. The cache should cool-off repeated requests that aren't cacheable. For example, if a given token / object results in a 403 (instead of a 404), we don't cache the response. However, this can still cause a high load if the same stupid client does the query over and over again: let's keep a separate, short-lived "naughty list" of requests we don't want to service.
6. I don't think the cache existence check is correct. You can see if an object is in a cache by requesting the first byte and then looking at the Age header. With a HEAD, I suspect all caches all claim to have the object.