S3 vhost customisation

[endgame]

Implement S3 vhost rewriting customisation using the design proposed by @basvandijk. The basic design is the same:

• request :: AWSRequest a => Service -> a -> Request a in class AWSRequest is now accepts the service to send the request to, instead of generators hardcoding defaultService. This allows the Request to be computed from the overriden Service instead of defaultService.
• We need to be able to determine the default service for a request type when doing initial signing, so we need a typeclass method service :: AWSRequest a => Proxy a -> Service somewhere. We apply overrides to it before passing it to request.
• It might be possible to avoid the additional typeclass method by making request :: AWSRequest a => (Service -> Service) -> a -> Request a, but every option I could think of seemed worse than a new typeclass method.

There are some differences to the original design (which I cherry-picked from @ivb-supercede's branch with generator fixes):

• The service function is a method of class AWSRequest a instead of a separate class AWSService a and making class AWSService a => AWSRequest a; I couldn't see much benefit in a separate typeclass. Am I wrong?
• Instead of a Bool, I added a sum type to match the S3 addressing style options

Because we're going to have to regenerate everything, I updated botocore as well. A full regeneration is available at endgame:s3-vhost-customisation-generation and will be merged once this branch lands. I have rebuilt the entire repo locally and it at least compiles.

Ping @basvandijk @ivb-supercede @kfigiela @akshaymankar @periodic who might be interested — please test the branch above.

@basvandijk / @ivb-supercede: Is it OK that I've cherry-picked your commits here?

Fixes #760 Closes #797

[ivb-supercede]

The service function is a method of class AWSRequest a instead of a separate class AWSService a and making class AWSService a => AWSRequest a; I couldn't see much benefit in a separate typeclass. Am I wrong?

I don't know enough to comment on this in general, since I just cribbed this from Bas' code. But in the case where AWSService is a superclass of AWSRequest, then this is design doesn't really make a difference - without any typeclass laws, what meaningful code can be written with only a AWSService instance?

Ping @basvandijk @ivb-supercede @kfigiela @akshaymankar @periodic who might be interested — please test the branch above.

Will do.

@basvandijk / @ivb-supercede: Is it OK that I've cherry-picked your commits here?

All good with me :+1:.

[kfigiela]

I will test this soon. If anyone needs a version with all services regenerated, it's available on my fork with the same branch name.

[kfigiela]

I can confirm that our integration tests work just fine with aws mocked with localstack and endpoint override configured not to use vhosts.

[ivb-supercede]

Looks like these changes work fine for us, for both real AWS usage and for local mocking with Moto.