Move computation of ShouldGenerateNewKey to KeyRingProvider

[amcasey]

It used to be the case that part of IDefaultKeyResolver.ResolveDefaultKeyPolicy's job was to determine whether the current default key was close enough to expiration that a new one ought to be generated. This didn't make sense as the definition of "too close" depended upon the refresh period and propagation time of the ICacheableKeyRingProvider. That is, the IDefaultKeyResolver had to make assumptions about how often it would be polled for changed.

The old logic was also very subtle and, as far as I was able to determine, slightly incorrect. Formerly, the presence of any key activated prior to the current default key's expiration date and not expiring during the next propagation cycle was considered an acceptable replacement. Several things seem strange about this:

1. The logic for finding a successor key is not the same as the logic for finding a preferred key (e.g. CanCreateAuthenticatedEncryptor is not checked)
2. The propagation window is counted forward from the current time, rather than backward from the expiration time
3. It's not immediately clear what happens if the successor key is unexpired at the end of the propagation window but expired before the default key's expiration time (maybe that's impossible or maybe that would be caught next refresh?)
4. As mentioned above, it doesn't seem like the resolver should know about the refresh period or make assumptions about how often it's called

Now, the ICacheableKeyRingProvider is responsible for determining whether the returned default key is close enough to expiration that a new key should be generated. It checks whether the current time is within one propagation cycle of the expiration time, padding by an extra refresh period to account for the fact that we don't know where in the refresh cycle expiration will fall (i.e. so that we never generate a new key less than a full propagation cycle ahead of when it's needed).

Part of #53654

[captainsafia]

LGTM with a small inline comment. Also worthwhile to document the change in meaning for DefaultKeyResolution.ShouldGenerateNewKey.

[amcasey]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[dotnet-policy-service]

Thanks for identifying a breaking change.

no assignees, after you commit this PR please take the following actions, as part of the breaking changes announcement process:

• Create an announcement issue by using the ASP.NET Core breaking change issue template.
• Link the breaking change announcement issue from this PR.
• Remove the needs-breaking-change-announcement label.