Add DownloadInitiated, Failed and Completed events

[GarrettBeatty]

Stacked PRs:

• ->Add DownloadInitiated, Failed and Completed events #4079
• Add UploadWithResponseAsync API #4062
• Add GetObjectResponse to TransferUtilityOpenStreamResponse mapping. #4076
• Add DownloadResponse mapping #4075

---

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 - in progress
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.

[Copilot]

Pull Request Overview

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

[Copilot]

The response parameter could potentially be null based on the calling code in DownloadCommand.async.cs line 148. Consider adding null validation in the constructor or documenting that a null response should never be passed, to prevent potential issues if the calling code changes.

Suggested change

	{
	{
	if (response == null)
	throw new ArgumentNullException(nameof(response), "Response cannot be null.");

[Copilot]

The DownloadWithLifecycleEvents and DownloadWithLifecycleEventsAndKey helper methods contain duplicated code for setting up event handlers (lines 2282-2295 and 2315-2328). Consider extracting the event handler setup into a shared helper method to reduce duplication and improve maintainability.

[GarrettBeatty]

copilot is saying that this could potentially be null but based on my reading of the code, if there is any failure we will throw exception early on, so it can never be null. thoughts?