[WIP] x509_certificate(_pipe): add regenerate option

[felixfontein]

SUMMARY

Adds a regenerate option to x509_certificate(_pipe) similar to the one of openssl_privatekey. This gives the user more fine-grained controlled when certificates should be regenerated.

This is a breaking change since it adjusts the behavior to the one of openssl_privatekey: if the certificate was broken, it will no longer be always regenerated, but only if regenerate is set to always or full_idempotence (or if force=true, which implies regenerate=always).

Fixes #295.

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

x509_certificate
x509_certificate_info

[felixfontein]

I'm wondering whether the regenerate option should have more/different values for certificates, or whether there should be multiple regenerate options (for different aspects).

(partial_idempotence and full_idempotence could maybe renamed to idempotence_without_times and idempotence_with_times.)

What do you all think about this?

[felixfontein]

(The failing tests are no surprise due to the breaking change. I haven't adjusted the tests yet, that's also why this PR is a WIP.)

[Ajpantuso]

I'm wondering whether the regenerate option should have more/different values for certificates, or whether there should be multiple regenerate options (for different aspects).

(partial_idempotence and full_idempotence could maybe renamed to idempotence_without_times and idempotence_with_times.)

What do you all think about this?

What you're suggesting sounds to me like a dict that describes an idempotency configuration where each suboption is an aspect of the comparison. never, fail, and always would still make sense in that case, but partial and full would lose meaning and become one choice that refers to the config. I think that would allow for better consistency across modules and avoid repetition in the descriptions (as would be the case if each idempotency config was it's own option). Pretty sure this level of effort exceeds what you were asking though.

[felixfontein]

I'm currently tending to not continue with this, but instead take #317.

[felixfontein]

Closing in favor of #317.