Ensure support for pull-through caches

[jonasfj]

A pull-though cache is just a simple HTTP cache... When working in data-center etc, we won't have cheap object storage available, so we have to do pull-through caches.

cloud-mirror can support this by taking the rawUrl choosing a cache server using something like: cacheServers[fnv(rawUrl) % cacheServers.length]...
So that if we have multiple cache servers, urls get distributed based on hash of the url...

The put operation for such a pull-through cache is pretty naive, as there is no copying, just choose a cache server and rewrite the url. This could be a special implementation CacheHandler as proposed in #9. Or we could do the redis and sqs messaging even if it is unnecessary and do a trivial implementation of StorageProvider.

Either way, when region detection based on ip ranges is moved to cloud-mirror (issue #6) it would be very nice to support backends that are essentially pull-through caches. Otherwise, support for data-center and providers like digital ocean or packet will be hard.

[jonasfj]

Note, when we move region resolution... We also want to move the CDN option in here.
Which is just a pull-through cache too.

[jonasfj]

@jhford, in thinking about this I realize that we don't want to implement a StorageProvider for pull-through caches...
Because redirecting to pull-through caches is really just url-rewriting that all, nothing more :)

So it's probably a special case that is handled in the API implementation. Because we can construct the result url immeidately and redirect to it immediately.

So let's ignore this for now, when thinking about StorageProvider and CacheMananger, simple url rewriting shouldn't get entangled with SQS and redis caches..