Support S3 request rewriting

[vagaerg]

I turned TestPresigningHeaders and TestPresignedRequests into abstract test classes, so unfortunately this results in a large diff. Diffing these files with their Abstract counterparts should provide useful insight.

This PR introduces functionality to redirect the bucket and key of an S3 request, in order to provide a virtualised view of a bucket.

Since the proxy does not decode the responses it gets back from S3, listing files or listing buckets will result in the real names being returned.

The authorisation logic happens with the original bucket and key and not the rewritten one. I believe this is a powerful way of letting users build abstractions on top of existing storage buckets, but it would need to be documented to ensure people understand how request rewriting changes the authorization flow.

[Randgalt]

Did you consider returning Optional<ParsedS3Request>? This would be more flexible as the plugin could adjust anything it wanted. wdyt?

[vagaerg]

I considered this, but the ParsedS3Request class has lots of fields and it could become error prone. Users would need to understand the different input streams the class can have for instance.
There's also the headers logic, where we rely on some headers having been stripped out of the ParsedS3Request so we don't send them to S3 (for instance, Authorization).

I feel that it is easier to expand the S3RewriteResult class in the future if we want to make it more extensible, than have to consider all the possible modifications people may make to our internal parsed request record.

Wdyt?