fix(lib-storage): replace UploadPart spread with field allowlist

[Zelys-DFKH]

Issue

#8020

Description

Upload.__doConcurrentUpload spreads ...this.params (typed as PutObjectCommandInput) into every UploadPartCommand. PutObjectCommandInput includes object-creation-only fields — IfNoneMatch, ContentType, ContentMD5, Metadata, ACL, StorageClass, ObjectLock*, and others — and S3 rejects them on the UploadPart API with NotImplemented (501) or MalformedXML.

This PR replaces the spread with an explicit allowlist of the fields UploadPartRequest actually accepts: Bucket, Key, the full Checksum* family, SSECustomerAlgorithm/Key/KeyMD5, RequestPayer, and ExpectedBucketOwner. Body, PartNumber, UploadId, and ContentLength are set explicitly as before.

Two intentional omissions:

• ContentMD5 — this.params.ContentMD5 is the whole-object MD5. Forwarding it to each part would be wrong. The UploadPartRequest.ContentMD5 field exists for per-part hashes, which callers can supply via request interceptors.
• ContentLength — already explicitly set to undefined in the existing code; no change.

CompleteMultipartUploadCommand continues to receive ...this.params at the end of the flow, so IfNoneMatch and other CompleteMultipartUpload-valid fields still work correctly there.

Note on PR #7994: That PR strips ContentMD5 via a denylist. This PR uses a full allowlist instead — more defensive against future PutObjectCommandInput additions silently leaking through. Happy to coordinate if the team prefers the denylist approach.

Testing

Added a regression test in the large buffers describe block that:

• forces the multipart path
• confirms IfNoneMatch, ContentType, and ContentMD5 don't reach UploadPartCommand
• confirms SSECustomerAlgorithm (valid for UploadPart) flows through
• confirms CompleteMultipartUploadCommand still receives IfNoneMatch

All 53 existing tests pass.

Checklist

• If the PR is a feature, add integration tests (*.integ.spec.ts) or E2E tests.
  • It's not a feature.
• My E2E tests are resilient to concurrent i/o.
  • I didn't write any E2E tests.
• I added access level annotations e.g. @public, @internal tags and enabled doc generation on the package. Remember that access level annotations go below the description, not above.
  • I didn't add any public functions.
• Streams - how do they work?? My WebStream readers/locks are properly lifecycled. Node.js stream backpressure is handled. Error handling.
  • No streams here.

[danyalahmed1995]

I think this still has the same root issue in a slightly narrower form.

The PR removes the broad ...this.params spread into UploadPartCommand, which fixes the reported IfNoneMatch failure. But the new allowlist still forwards top-level checksum fields from Upload params into every part upload.

I tested this locally with a temporary regression test using:

ChecksumSHA256: "object-level-sha256-base64=="

on the Upload params. The focused test fails because both mocked UploadPartCommand calls receive that same ChecksumSHA256 value.

That looks like the same class of bug as ContentMD5: the value can be object-level at the Upload API boundary, but UploadPartCommand interprets checksum fields as per-part checksums. So the current allowlist can still create invalid multipart requests for users passing object-level checksum values.

Because of that, I don’t think the safe boundary is “fields accepted by UploadPartCommand.” Some fields are accepted by UploadPartCommand, but should only be passed if lib-storage computed them for that specific part. For user-supplied top-level params, the allowlist probably needs to exclude concrete Checksum* values too, not just ContentMD5.

[Zelys-DFKH]

Good catch. You're right that the allowlist still leaks object-level checksums into UploadPart. ChecksumSHA256 at the Upload boundary is a whole-object hash; sending it as a per-part value causes BadDigest. Same class of bug as ContentMD5.

Pushed 22fc2bc: dropped the concrete Checksum* values from the allowlist, kept only ChecksumAlgorithm. That one is a directive (e.g. "SHA256"), not a precomputed hash, so the SDK middleware can still compute a per-part value from it. Extended the regression test to assert ChecksumSHA256 doesn't reach UploadPart, plus a single-part PUT path test confirming object-level checksums are still preserved when multipart isn't used. 54/54 passing locally.

This complements #7990 (fail-fast on full-object Checksum* with multipart). Either this or your #8042 closes the bug; happy to defer to whichever the team prefers.