s3: expose EventualConsistency

s3: expose EventualConsistency

By doing this, we allow test code external to
goamz to adjust the timeout duration. It's particularly
useful when running against s3test - by changing
this we can reduce the time it takes to test
launchpad.net/juju-core/environs/ec2 from
3 minutes to 6 seconds.

An alternative to this CL is at https://codereview.appspot.com/12740044

https://code.launchpad.net/~rogpeppe/goamz/expose-consistency-strategy/+merge/180087

(do not edit description out of merge proposal)

[rog, 2013-08-14 10:35:51]

Please take a look.

[dimitern, 2013-08-14 10:38:06]

LGTM

[gz, 2013-08-14 10:38:32]

LGTM.

[rog, 2013-08-14 11:23:53]

Please take a look.

[niemeyer, 2013-08-14 13:25:28]

NOT LGTM

https://codereview.appspot.com/12918044/diff/8001/s3/export_test.go
File s3/export_test.go (right):

https://codereview.appspot.com/12918044/diff/8001/s3/export_test.go#newcode9
s3/export_test.go:9: func SetAttemptStrategy(s *aws.AttemptStrategy) {
A few issues here.

First, why wasn't this function exposed instead?  The term "Eventual
Consistency" means something very different from what this does, and the attempt
strategy also handles issues unrelated to the whatever model of consistency the
server chooses to implement.

It also feels like a poor idea to offer people the chance to tweak individual
parameters of the attempt strategy. People can easily change a single one of
them, and then if we choose to tweak the attempt strategy, it will produce
unintended results.

Finally, it still feels like a bad idea to expose this in the API, as it's an
internal implementation detail we may want to change to improve the reliability
of the package. Exposing it will mean we can not revamp what an implementation
strategy means.

Instead, I'd suggest understanding what you're really trying to do, and being
more precise in what you mean. What do you *really* need?  Shortening the
timeout?  Disabling retries altogether?  We can have a function that does the
specific action intended.