[KeyVault] Consider updating LRO implementations to use OperationInternal class

[kinelski]

Consider updating implementations where applicable for Key Vault LROs (follow-up of #19105).

Useful links:

• Operation Internal class
• Example of LRO implementation (Form Recognizer)

[heaths]

We only have 1 true LRO. The others are pseudo-LROs that poll for state and cannot use OperationInternal directly.

As for CertificateOperation, the service returns a non-standard RetryAfter header (no dash) so we'd need to be able to override that for any possible benefit. Could changes be made to OperationInternal to provide some customization, e.g. make the class partial and let us supply retry headers or something?

/cc @pakrym

[kinelski]

Sure. We could make it an editable list of headers (maybe two lists depending on whether it counts seconds or milliseconds). Would it be worth adding the header directly to the OperationInternal class? Do you know of any other services using the same header?

[heaths]

I suppose it really depends on any potential perf impact of making the header list extensible vs. adding it. I would hope Key Vault is the only service sending back "RetryAfter". Even if we did add it to the list of supported headers, I would add it last to avoid impacting the perf of all the other services. In fact, I wonder if we can glean from telemetry what the right order should be to optimize for services that send one over another. Or, I suppose, use a HashSet but with only a few headers that, too, is probably more expensive than searching an O(N) list of a few items.

[heaths]

After talking with @pakrym about #20667 we could probably take this one for at least the pseudo-LROs. Pulling it in for consideration.

[heaths]

FWIW, Key Vault is sending back Retry-After and not RetryAfter, nor can I find any evidence it ever did send RetryAfter. 😕