Fix keyrotation warning

[irbekrm]

This PR improves the warning that is thrown when a user has changed some key size or algorithm in Certificate's spec, but cert-manager is unable to regenerate the private key because .spec.rotationPolicy is set to Never or is unset.

At the moment user would see this warning on cert's spec:

  Warning  DecodeFailed  30m   cert-manager-certificates-key-manager  Existing private key in Secret "myib-prod-ca" does not match requirements on Certificate resource, mismatching fields: [spec.keySize]

I have changed it to:

Warning  CannotRegenerateKey  15s (x2 over 15s)  cert-manager-certificates-key-manager      User intervention required: existing private key in Secret "test1" does not match requirements on Certificate resource, mismatching fields: [spec.privateKey.size], but cert-manager cannot create new private key as the Certificate's .spec.privateKey.rotationPolicy is unset or set to Never. To allow cert-manager to create a new private key you can set .spec.privateKey.rotationPolicy to 'Always' (this will result in the private key being regenerated every time a cert is renewed)

(maybe too verbose?)

Fixes #5183

I have also considered that perhaps we could simply recreate the key in this case, however this would be a change in behaviour. At the moment the description of cert.spec.privateKey.rotationPolicy does explicitly state that user intervention is required if a key spec field has changed, but the policy is not 'Always'

Updates warning message that is thrown if issuance fails because private key does not match spec, but private key regeneration is disabled. See https://github.com/cert-manager/cert-manager/pull/5199.

/kind cleanup

[irbekrm]

these are probably leftover from alpha/beta structure when the privateKey field did not exist yet

[irbekrm]

/milestone v1.9

[irbekrm]

/test pull-cert-manager-e2e-v1-24

[SgtCoDFish]

/lgtm
/approve
/hold

I think this seems an obvious win and changing the error to reasonCannotRegenerateKey makes sense.

I think there's a small chance someone might be filtering logs based on the old error code specifically, right, making this a change in behaviour?

I think that's totally reasonable, but would it be worth maybe adding a release note to this PR just noting the change?

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: irbekrm, SgtCoDFish

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [SgtCoDFish,irbekrm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[irbekrm]

I think there's a small chance someone might be filtering logs based on the old error code specifically, right, making this a change in behaviour?
I think that's totally reasonable, but would it be worth maybe adding a release note to this PR just noting the change?

Thanks @SgtCoDFish and thanks for the xkcd 😄 I've added a release note

[irbekrm]

/hold cancel