Fix aws-sigv4 canonical request formatting fallibility

[ysaito1001]

This PR attempts to address issue 711 where signing a request can cause panic! if a CanonicalRequest contains invalid UTF-8 in the header value.

The PR intentionally starts with a simple solution that makes a given test pass before we commit ourselves to start refactoring CanonicalRequest to support a special formatting function, which will probably be more expensive to do so. If the solution described in this PR works, that is great but if not, we can certainly switch to the refactoring ideas mentioned in the open issue.

The rationale behind the code changes is to make validating UTF-8 in the header value be part of an invariant of CanonicalRequest. That is, by the time CanonicalRequest has been successfully constructed by CanonicalRequest::from, we can guarantee that the type always contains valid UTF-8 in the header value. That way, we don't need to wait to catch invalid UTF-8 in the header value until we call to_string on CanonicalRequest (here).
That being said, the proposed approach may be inefficient because of eager checking of valid UTF-8 in the header value within normalize_header_value, especially when a CanonicalRequest does not need to be signed (in which case I assume to_string on the CanonicalRequest does not need to be called in the execution path).

This PR comes with a test provided in the open issue as well as a small test for normalize_header_value to exercise the part that has been updated.

I would appreciate if the reviewers with more background knowledge could assess the code changes from different perspectives.

[rcoh]

this looks great! do you mind making a few small improvements:

• since Display is still infallible, we should add proptesting or fuzzing to the input to the signer to ensure that no matter what the input is, we can't cause a runtime panic
• will you add a test (and probably make a small update to the error) to ensure that the error that we emit gives a clear message about why signing failed? I think the current error probably won't indicate anything about the problem being a header

[ysaito1001]

Thanks @rcoh ! I took a stab at incorporating the feedback.

we should add proptesting or fuzzing to the input to the signer to ensure that no matter what the input is, we can't cause a runtime panic

I converted test_signing_utf8_headers to a proptest (renamed it and moved it to sign.rs) to exercise a wide range of inputs for request header values. As far as I can see, besides the the passed-in Formatter returning an error, the Display trait implementation for CanonicalRequest can only fail because of std::str::from_utf8 for HeaderValue. So I specifically targeted the proptest at that use case. However, what you requested seems like exercising a higher entity than HeaderValue. To be on the same page, if the proptest is not aligned with what you thought, could you tell me the name of system under test, i.e. a type or a function to test, so I can test it further.

will you add a test (and probably make a small update to the error) to ensure that the error that we emit gives a clear message about why signing failed?

I have added an error type InvalidHeaderError in the canonical_request module (since I was not sure whether I put it in the right place, please let me know if you want me to move InvalidHeaderError to its own error module or somewhere else). I have added a test in sign.rs to verify that if signing failed we should expect an InvalidHeaderError. I have used downcast_ref to compare the actual error type against the expected one but did not attempt to print out a diagnostic message and use it for verification as comparing against a raw string for verification can make the test brittle (please let me know if you think otherwise, I am open to suggestions). FYI, if we were to print an error when signing failed, it would look something like:

invalid UTF-8 contained in header value: invalid utf-8 sequence of 1 bytes from index 0

[jdisanti]

This looks good! I think can merge it as is, although it would be nice to improve the overall error situation in this crate.