Consider how to handle default polling interval for LROs

[jhendrixMSFT]

The current track 2 implementation requires that callers pass a polling interval to be used if the service doesn't return a retry-after header. While this is an improvement over track 1, there is a concern that customers might have a difficult time in selecting an appropriate value. To add to the complexity, there really is no universal one-size-fits-all value. For reference, the ARM RPC spec specifies a default value of 60 seconds in absence of a retry-after header, however some teams have expressed concerns that this value is too high in some scenarios (this comes back to the no universal value problem). Conversely, polling too frequently can lead to quota exhaustion (thus throttling) when performing operations at scale (e.g. Terraform). Finding the right balance is often context-dependent, which is why we required callers to provide a value in the first place (e.g. AKS wants complete control over this, and finds our current track 1 design cumbersome).

One idea, provided by the AKS team, is that different RPs would specify their own, appropriate, default polling interval. How this would be integrated with the SDK is TBD. And we'd have to decide how to handle the case where RPs don't supply a value.

Ideally, RPs would always return an appropriate retry-after header value. All SDKs would benefit from such a solution.

[JeffreyRichter]

Let's not do anything now. But, let's add a comment to give customers a suggestion.
We can do something in the future if a customer problem arises.

[jhendrixMSFT]

Fixed in preview.30 of the code generator.