azure-core retry policy should check retry-after-ms before retry-after

[kristapratico]

Related code:

azure-sdk-for-python/sdk/core/azure-core/azure/core/pipeline/policies/_utils.py

Lines 77 to 94 in 727f510

	def get_retry_after(response: PipelineResponse[HTTPRequestType, AllHttpResponseType]) -> Optional[float]:
	"""Get the value of Retry-After in seconds.
	:param response: The PipelineResponse object
	:type response: ~azure.core.pipeline.PipelineResponse
	:return: Value of Retry-After in seconds.
	:rtype: float or None
	"""
	headers = case_insensitive_dict(response.http_response.headers)
	retry_after = headers.get("retry-after")
	if retry_after:
	return parse_retry_after(retry_after)
	for ms_header in ["retry-after-ms", "x-ms-retry-after-ms"]:
	retry_after = headers.get(ms_header)
	if retry_after:
	parsed_retry_after = parse_retry_after(retry_after)
	return parsed_retry_after / 1000.0
	return None

We should check the value of retry-after-ms before retry-after. Some services will send both headers, and with the current code we will use retry-after when a shorter / sub second wait time might be present in retry-after-ms. Here is the logic other language SDKs follow:

• If the retry-after-ms header key is present, use its value as the number of milliseconds to delay
• Else, if the x-ms-retry-after-ms header key is present, instead use its value as the number of milliseconds to delay
• Else, if the retry-after header key is present, use its value as the number of whole seconds to delay
• Else, fall back to standard fallback heuristics to calculate a retry delay

We should update the code in azure-core to check the retry-after-ms headers in advance of the retry-after header.

@annatisch