Handle checksum for unseekable 0-length s3 request body

[Madrigal]

• Handle checksum for unseekable body with 0 content length

Fixes #3080

The SDK calculates checksums differently depending on whether the request body can be rewinded (is seekable) or not. Bodies that we cannot rewind have to use trailing checksums, where we follow a different algorithm to calculate the checksum.

We had an issue where we treated any 0 content-length as "content length unknown", when in reality the sentinel value for not set is -1. Due to this, the SDK would

1. Set this as "calculate using trailing checksum"
2. Content length was set to the result of getRequestStreamLength (-1 instead of the 0 set by the customer)
3. Since it was set to -1, no content-length header was set and the request would fail.

This has changed now so we actually treat 0 as a valid value and we send the right content header.

Wait, didn't we already have a test for this?

Yes! as you can see, we have a test named https empty stream unseekable. However, there are some nuances on how these requests are actually treated when we call SetStream. The test used to have bytes.Buffer, whose length can be identified by using Len(). This makes it take a different path on the underlying implementation

func streamLength(stream io.Reader, seekable bool, startPos int64) (size int64, ok bool, err error) { if stream == nil { return 0, true, nil	} if l, ok := stream.(interface{ Len() int }); ok { return int64(l.Len()), true, nil // ------> takes this path	} if !seekable { return 0, false, nil // -------> instead of this path	} // ...

so it's treated as seekable later on the implementation. Changed the tests to fix this