fix S3 UploadPart logic when cancelling/error a request

[bentsku]

Motivation

As reported with #9851, we would face an issue when cancelling/error an UploadPart request and retrying on the same PartNumber.
This was due because of our ephemeral MultipartUpload object is not fully stateless, and keeps the EphemeralS3StoredObject in a dict to allow easier "fusion" of all underlying parts when completing (it does not have to recreate the EphemeralS3StoredObject on top of the LockedSpooledTemporaryFile).
Code here:

localstack/localstack/services/s3/v3/storage/ephemeral.py

Lines 237 to 250 in fb182b7

	def open(self, s3_part: S3Part) -> EphemeralS3StoredObject:
	"""
	Returns an EphemeralS3StoredObject for an S3Part, allowing direct access to the object. This will add a part
	into the Multipart collection. We can directly store the EphemeralS3StoredObject in the collection, as S3Part
	cannot be accessed/read directly from the API.
	:param s3_part: S3Part object
	:return: EphemeralS3StoredObject, most often to directly `write` into it.
	"""
	if not (stored_part := self.parts.get(s3_part.part_number)):
	file = LockedSpooledTemporaryFile(dir=self.upload_dir, max_size=S3_MAX_FILE_SIZE_BYTES)
	stored_part = EphemeralS3StoredObject(s3_part, file)
	self.parts[s3_part.part_number] = stored_part
	return stored_part

However, this created an issue when the request would error/cancel, because the EphemeralS3StoredObject kept the reference to the S3Part that errored (created in the provider operation which raised an Exception, with localstack.services.s3.v3.storage.ephemeral.EphemeralS3StoredMultipart.open). When creating a new S3Part in a non-failing provider operation, the asynchronous calculation of the ETag due to the aws-chunked encoding would not set the ETag to the new S3Part but to the previously created one, hence the returned ETag set to None.

Changes

The simple fix is to simply remove the part entry for the underlying storage if the writing of that part fails. It could maybe be wrapped in a context manager which would clean up only if the operation fails, but this is simple and clear what it does.

I've also added a test to verify the fix, ran the external soto test suite and validated that it now works.

[github-actions]

S3 Image Test Results (AMD64 / ARM64)

    2 files  ±0      2 suites  ±0   3m 15s ⏱️ +3s
382 tests +1  332 ✔️ +1    50 💤 ±0  0 ❌ ±0 
764 runs  +2  664 ✔️ +2  100 💤 ±0  0 ❌ ±0 

Results for commit 5dc1173. ± Comparison against base commit dd9b2b0.

[coveralls]

coverage: 84.036% (-0.006%) from 84.042%
when pulling 5dc1173 on fix-s3-cancel
into dd9b2b0 on master.

[github-actions]

LocalStack Community integration with Pro

       2 files  ±0         2 suites  ±0   1h 14m 16s ⏱️ + 2m 36s
2 409 tests +1  2 181 ✔️ +1  228 💤 ±0  0 ❌ ±0 
2 410 runs  +1  2 181 ✔️ +1  229 💤 ±0  0 ❌ ±0 

Results for commit 5dc1173. ± Comparison against base commit dd9b2b0.

[steffyP]

LGTM 👍 😄
Thanks for the detailed explanation and adding a new test, which will help detect any regression in the future 🚀