Support Juju's `User Secrets` for supplying confidential material

Describe the bug

Currently the way to provide things like passwords is via charm configuration. Juju 3.3 and beyond has implemented support for User Secrets, that allows you to supply content that you consider sensitive (passwords, private keys, etc)

To Reproduce

Configuring your httprequest-lego-k8s-operator currently expects you to pass a couple of things that might be considered sensitive as standard charm config. eg:

juju config httprequest-lego-k8s \
    email='my-email@example.com' \
    httpreq_endpoint='https://lego-certs.example.com' \
    httpreq_password='${YOUR-PASSWORD}' \
    httpreq_propagation_timeout=600 \
    httpreq_username='${YOUR-USERNAME}'

While the visibility of that content is restricted to users and the application in question (other applications cannot ask for the config of an app that is not theirs), it is still content that would show up in juju config, and is stored in plain text inside juju.

With secrets, at least there is the option to store them in something like vault, and by default the content isn't shown unless you explicitly ask for the secret content, and it is only available to users with Write permission on a model (vs anyone with Read).

Expected behavior

It does complicate the workflow a bit, because you have to have a secret in order to grant and share it to an application, but you also have to have the application in order to have a target to grant. So the steps become:

juju deploy httprequest-lego-k8s
SECRET_ID=`juju add-secret NAME_FOR_ME password=XXXX username=YYY`
juju grant-secret NAME_FOR_ME httprequest-lego-k8s
juju config httprequest-lego-k8s httpreq_secret=$SECRET_ID

You also need to add a config entry (httpreq_secret) with type "secret" to the charm, and then respond to the config-changed event that happens in step 4 above. You would also need to handle secret-changed events in the case that a user decides to juju update-secret NAME_FOR_ME.)

canonical / httprequest-lego-k8s-operator