s3: support for encryption, storage class, custom headers

[kobmic]

Implemented server side encryption, added s3 storage class and custom headers. Fixes #109

Tried not to break the current S3Client multipartUpload API, even if I'm not to happy with always passing CannedAcl and MetaHeaders. Would be nicer to have Options for these arguments, i.e. always passing the default 'CannedAcl.Private' makes it impossible to add a custom 'x-amz-grant-read' header (conflicting).

[kobmic]

Saw that Travis build of my PR failed with an error in AwsLambdaFlowSpec and that other PRs had the same issue - anything I can do to make Travis happy?

[johanandren]

We're tracking that in #235, I guess someone re-triggered the build because this PR is green now.

[svezfaz]

@kobmic I agree, the S3Client API looks a bit brittle. I don't think we should go great length not to break it.. this should be all experimental ATM? Might be a good idea to change S3Client API now to use optional params.

[kobmic]

If it's ok to change the current API I would refactor my PR, move the params to the new S3Header case class and make them optional. What do you think?

[svezfaz]

It makes sense to me. @johanandren WDYT?

[johanandren]

I agree that this is better, but could we provide a @deprecated overload of the method that keeps the old signature? I'ts always unpleasant to have end user code break.

[kobmic]

The compiler won't let me have multiple overloaded alternatives of method 'multipartUpload' with default arguments (which I still want in both cases). So I ended up with a 'multipartUploadWithHeaders' alternative without deprecating the old API.

[johanandren]

LGTM!