Motivation

Reported in #9387: when creating a multipart upload on an existing key, we would not truncate the key before overwrite it like we do when calling PutObject.

This was due to our optimization with append on the StoredS3Object, which was stateless, and bad oversight on my side.

Flow for the sample in the linked issue is:

• CreateMultipart on key test
• UploadPart with value "first"
• CompletePart on key test
• GetObject on key test -> value is "first"
• CreateMultipart again on key test
• UploadPart with the result of previous GetObject ("first") + "second" -> value = "firstsecond"
• CompleteMultipart on key test
• GetObject on key test, result should be "firstsecond"

Issue was appending on top of existing key, resulting in "firstfirstsecond".

Changes

Added a new truncate method to the base S3StoredObject to be able to reset the file from the StoredMultipart.
Add s3_object.seek(0) + s3_object.truncate() in complete_multipart so that the existing file object representing the key is properly truncated before we write and we do not append the multipart on top of the existing key.

Added an AWS validated test validating this behaviour.