rework errors

[aajtodd]

Issue #, if available: https://github.com/awslabs/aws-s3-transfer-manager-rs/issues/13

Description of changes:

Refactor our error representation into a single struct with an ErrorKind.

Rationale

Smithy errors are designed based on whether they are “informative” or “actionable” (see RFC-0022).

Below are the actual modeled SDK errors for the operations the S3 transfer manager is expected to invoke:

pub enum ListObjectsV2Error {
    NoSuchBucket(NoSuchBucket),
    Unhandled(Unhandled),
}

pub enum HeadObjectError {
    NotFound(NotFound),
    Unhandled(Unhandled),
}

pub enum GetObjectError {
    InvalidObjectState(InvalidObjectState),
    NoSuchKey(NoSuchKey),
    Unhandled(Unhandled),
}

pub enum PutObjectError {
    Unhandled(Unhandled),
}

pub enum UploadPartError {
    Unhandled(Unhandled),
}

pub enum CreateMultipartUploadError {
    Unhandled(Unhandled),
}

pub enum CompleteMultipartUploadError {
    Unhandled(Unhandled),
}

pub enum AbortMultipartUploadError {
    NoSuchUpload(NoSuchUpload),
    Unhandled(Unhandled),
}

There are not many variants here worth propagating up or that a user would find actionable. As such it makes little sense to expose them directly. The exception to this would be to access the raw HTTP response and/or metadata (e.g. request ID) but we should be able to capture that and expose it more conveniently for users without resorting to exposing the raw error.

The rest of our errors are more informative or bugs (e.g. invalid user input, runtime errors from poisoned mutex, join errors, etc).

This lead us to settle on a single struct with ErrorKind enum similar to std::io::Error.

Open Questions/Future

1. Error representation for when an error is encountered while already processing an error (e.g. upload of a single part fails; failure policy is to abort, we invoke AbortMutlipartUpload and that fails for some reason.) Do we make the secondary error available somehow or somehow expose that "cleanup" failed?
2. Metadata and raw HTTP response headers
   • We should be able to capture this and expose it fairly easily from the underlying SdkError

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.