backup: Bump gocloud.dev to v0.47.0 for S3-compatible backup sink (19-4-stable backport)

What does this MR do?

Backport to 19-4-stable of !9466 (merged).

Bumps gocloud.dev from v0.46.0 to v0.47.0 to fix server-side repository backups against stricter S3-compatible object stores, and adds a regression test.

Depends on !9471 (merged) (moves this branch to Go 1.26). gocloud v0.47.0 declares go 1.26.0, so this MR cannot build until !9471 (merged) merges. Merge !9471 (merged) first, then this.

Why

The server-side backup sink uploads via gocloud.dev/blob/s3blob. In v0.46.0 the s3blob writer set RequestChecksumCalculation on the S3 client but not on the transfermanager.Client it created. The transfer manager's own setting wins and defaults to WhenSupported, so request_checksum_calculation=when_required (which the backup sink injects by default for custom endpoints) never reached the upload-signing path. Uploads carried a flexible checksum, and on larger objects the aws-chunked streaming format (x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER), which some S3-compatible stores (e.g. Dell ECS) reject with HTTP 400 XAmzContentSHA256Mismatch.

This was a regression in gocloud v0.46.0; v0.44.0 and v0.45.0 carried the setting onto the old s3/manager uploader. gocloud v0.47.0 threads it into the transfer manager's own options (https://github.com/google/go-cloud/pull/3766).

No Gitaly configuration change is required.

Contents

• Bump gocloud.dev to v0.47.0.
• Add TestS3SinkUploadSendsUnsignedPayload, which points the sink at a fake S3 HTTP server and asserts the PutObject carries no flexible checksum header. It fails on v0.46.0 and passes on v0.47.0.

Reported in https://gitlab.com/gitlab-com/request-for-help/-/work_items/5649