aws/request: Reorganize retry behavior to reduce separation

[jasdel]

Reorganizes the SDK's retry utilities to follow a consistent code path.
Request.IsErrorRetryable is the primary entry pointer for determining if
a request error should be retryable instead of split between
Request.Send and DefaultRetryer calling IsErrorRetryable. This also
gives the implementation of the Retryer interface consistent control
over when a request will be retried.

Also adds support for request and service specific API error retry and
throttling to be enabled by specifying API error codes before a request
is sent. The "RetryErrorCodes" and "ThrottleErrorCodes" members were added to
request.Request struct. These are used by the Request's IsErrorRetryable
and IsErrorThrottle respectively to specify additional API error codes
that identify the failed request attempt as needing to be retried or
throttled. The DefaultRetryer uses both of these methods when
determining if a failed request attempt should be retried.

Related to #1376

TODO

• Need tests for new members added.

[thastings3]

@jasdel when we wrap the aws clients Publish(*sns.PublishInput) (*sns.PublishOutput, error) with some of our own backoff/jitter we are using the error returned and passing that into request.IsErrorRetryable(error) which is causing us to always get true back for what we consider successful cases of nil error due to the addition of the case nil: return true in this pr inside of shouldRetryError.

My question is - are we using this helper function incorrectly on our side?
For now I have just added a nil check into our wrapper so its not a big deal but I was just curious if there was something more here.
Thanks!

[jasdel]

Thanks for reporting this issue @thastings3. I created #2773 to track this bug. Passing nil into IsErrorRetryable documents that passing in nil should return false, and I reproduced this, and have a fix out for this issue shortly.