Add DownloadInitiated, Failed and Completed events

[GarrettBeatty]

Stacked PRs:

• ->Add DownloadInitiated, Failed and Completed events #4079
• add UploadWithResponseAsync api #4085
• Add GetObjectResponse to TransferUtilityOpenStreamResponse mapping. #4076
• Remove AmazonWebServiceResponse as base class for transfer utility repsonse objects. #4087

---

Description

This change adds progress listeners for "initiated", "complete", and "failed" lifecycle events for the DownloadCommand Consumers can subscribe to these callbacks to receive notifications when a simple upload starts, finishes successfully, or fails. Its similar to #4059 but for downloads

Motivation and Context

1. To adhere to the SEP

Testing

1. f0cb4050-fb2c-4fb0-b489-280eb3313ca9 - pass
2. Integration tests

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[Copilot]

Pull Request Overview

This PR adds lifecycle events (DownloadInitiatedEvent, DownloadCompletedEvent, and DownloadFailedEvent) to the S3 TransferUtility download functionality, providing developers with better visibility into download operations.

Key changes:

• New event handlers and event argument classes for download lifecycle events
• Integration of events into the DownloadCommand execution flow
• Comprehensive integration tests covering individual and combined lifecycle events

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
sdk/src/Services/S3/Custom/Transfer/TransferUtilityDownloadRequest.cs	Adds three new public events (DownloadInitiatedEvent, DownloadCompletedEvent, DownloadFailedEvent) with corresponding event argument classes and internal event-raising methods
sdk/src/Services/S3/Custom/Transfer/Internal/_async/DownloadCommand.async.cs	Implements event firing at appropriate points in the download lifecycle, tracks total bytes from response headers, and maps the final response
sdk/src/Services/S3/Custom/Transfer/Internal/DownloadCommand.cs	Adds event firing helper methods and tracks total transferred bytes using Interlocked operations for thread safety
sdk/src/Services/S3/Custom/Model/GetObjectResponse.cs	Adds Request property to WriteObjectProgressArgs to provide access to the original download request
sdk/test/Services/S3/IntegrationTests/TransferUtilityTests.cs	Adds five new integration tests covering individual events and complete lifecycle scenarios
generator/.DevConfigs/9d07dc1e-d82d-4f94-8700-c7b57f872123.json	Adds dev config for version bump

[Copilot]

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

[Copilot]

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

[Copilot]

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

[GarrettBeatty]

not actually sure if interlocked is needed here. but added to be consistent with upload

[philasmar]

nit: be more descriptive that this is for the transfer utility

[philasmar]

why does this need to be here? what would this look like when this operation is generated? and why is it not internal at the very least?

[GarrettBeatty]

if you expand the code more. this is actually inside the WriteObjectProgressArgs class (Which is just located in the GetObjectResponse.cs file for some reason). This is used for in progress event when downloading.

ive put the new event progress stuff (initiated, failed, completed) in the TransferUtilityDownloadRequest class (which is consistent with upload).

[philasmar]

the logic looks sound to me but copilot is convinced that it can be null. Maybe be more defensive with it if there's a concurrency situation we're not considering.