feat(retry): add configurable link recovery delay

[j7nw4r]

Allows for configuration which fixes the issue: #25356

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to module CHANGELOG.md are included.
• MIT license headers are included in each file.

[Copilot]

Pull Request Overview

This PR adds a configurable link recovery delay feature to the Azure Event Hubs SDK, addressing issue #25356. The feature allows users to specify a custom delay for retries after AMQP link recovery failures, instead of using the default exponential backoff.

Key changes:

• Added LinkRecoveryDelay field to RetryOptions to configure fixed delays for link recovery retries
• Enhanced RetryFnArgs with UseLinkRecoveryDelay() method to signal when link recovery delay should be used
• Updated retry logic to apply the link recovery delay when appropriate, with support for zero (use exponential backoff), positive (fixed delay), and negative (no delay) values

Reviewed Changes

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

Show a summary per file

File	Description
sdk/messaging/azeventhubs/internal/exported/retry_options.go	Added LinkRecoveryDelay field to RetryOptions with comprehensive documentation
sdk/messaging/azeventhubs/internal/utils/retrier.go	Implemented logic to use link recovery delay when signaled, added UseLinkRecoveryDelay() method
sdk/messaging/azeventhubs/internal/utils/retrier_test.go	Added comprehensive test coverage for link recovery delay scenarios
sdk/messaging/azeventhubs/internal/links_recover.go	Updated RecoverIfNeeded() to accept RetryFnArgs and call UseLinkRecoveryDelay() for link recovery
sdk/messaging/azeventhubs/internal/links_unit_test.go	Updated all RecoverIfNeeded() calls to pass RetryFnArgs parameter
sdk/messaging/azeventhubs/internal/links_test.go	Updated all RecoverIfNeeded() calls to pass RetryFnArgs parameter
sdk/messaging/azeventhubs/CHANGELOG.md	Added entry documenting the new configurable link recovery delay feature

Comments suppressed due to low confidence (1)

sdk/messaging/azeventhubs/internal/utils/retrier.go:100

• When ResetAttempts() is called, the useLinkRecoveryDelay flag is not being reset. This means if a link recovery delay was set before calling ResetAttempts(), it will continue to be applied in the subsequent retry attempts after the reset, which may not be the intended behavior. Consider resetting useLinkRecoveryDelay to false when args.resetAttempts is true, similar to how the iteration counter is reset.

		// Capture the flag for the next iteration
		useLinkRecoveryDelay = args.useLinkRecoveryDelay

		if args.resetAttempts {
			log.Writef(eventName, "(%s) Resetting retry attempts", prefix())

			// it looks weird, but we're doing -1 here because the post-increment
			// will set it back to 0, which is what we want - go back to the 0th
			// iteration so we don't sleep before the attempt.
			//
			// You'll use this when you want to get another "fast" retry attempt.
			i = int32(-1)
		}