Certhandler secrets vault

[PietroPasotti]

Issue

certhandler is overly complicated, storing public data in too many juju secrets

Solution

• remove two of the three secrets, only store the privkey in a secret and retrieve csr and chain as needed from the relation data
• instead of storing secret ids in relation databags, rely on hardcoded secret labels to always know what secret to pick
• generate privkey on-demand and use the secret storage to persist and verify if we've generated it already
• automatically detect if juju supports secrets, and if not fall back to a 'peers' peer-relation backed storage solution for the private key (as plaintext).
• automatically migrate from peer to secrets- backend if on charm-upgrade we obtain access to secrets

Testing Instructions

A good test would be:

• deploy cos-lite
• jhack sync the lib to all charms who use it
• deploy self-signed certs and imatrix fill

Tandem pr: canonical/traefik-k8s-operator#346

[sed-i]

Great @PietroPasotti.
Can you link to the tandem PR?

[PietroPasotti]

@sed-i tandem pr: canonical/traefik-k8s-operator#346

[PietroPasotti]

Traefik's TLS itests passed AKA failed but for the wrong reasons. Merging away.

[sed-i]

Traefik's TLS itests passed AKA failed but for the wrong reasons. Merging away.

The linked itests are loki, not traefik. Traefik's itest failed for something that looks relevant:
https://github.com/canonical/traefik-k8s-operator/actions/runs/8925027611/job/24512805931?pr=346#step:6:1131

Scratch that, it's forward_auth that failed.