feat(lro): honor retry-after in the initial response

[archerzz]

Description

According to the specs(here and here), in LRO, the initial response (e.g. the response of the initial request) can carry retry-after header, which suggest the clients should wait the given time before sending the 1st polling request.

Return HTTP code 202 (Accepted) with a Location header and, optionally, a Retry-After header.

In track2, we haven't implemented that. The benefits are:

• optimizing performance since we could reduce the number of polling requests
• some services may not correctly implement the LRO logic, sending polling request too soon could cause error. Note that retry-after is a gentleman protocol, and the clients can choose not to follow it.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[annelo-msft]

@archerzz, could you share which clients depend on this feature, so we can prioritize it correctly?

[heng-liu]

App Configuration.
When migrating from Track1 SDK to Track2 SDK, we started to encounter this issue.
The LRO is aborted when the first polling request failed with 404.

[archerzz]

@archerzz, could you share which clients depend on this feature, so we can prioritize it correctly?

@annelo-msft I've included you in the original email thread. It's AppConfiguration.

[annelo-msft]

Would it be possible to provide a repro case for the specific operation that is not respecting the header interval? Azure.Core types should be respecting the RetryAfter header on a response if it’s available, as part of the default DelayStrategy implementation. Because of this, I'm interested to understand the specific case where this is not happening. Thanks!