feat: Support for wrap TTL on vault_kv interface

[skatsaounis]

This PR enables the usage of wrapping tokens by the Requirer part of vault_kv interface, as something optional.

This PR will enable vault_kv integration with charms that require a wrapping token instead of the role secret ID, like maas-region. MAAS can be integrated with Vault by providing approle details, as described in the relevant docs section.

[kayra1]

One thing I'm unsure of, but I don't have a strong opinion on (yet 😆 ) is whether we want to

1. Overload the response (i.e. it could return a wrapped token, or a secret ID in the same field).
2. Make that implicit on whether we have received a wrap_ttl or not.

I don't have any suggestions here, so maybe this is just noise, but I thought it was worth mentioning in case it sparks any discussion.

The way I see it is, passing secret-id's instead of secrets fulfills almost the same role as putting some response into a cubbyhole and passing a token for it. The main difference being the secure explicit granting mechanism with juju and the more flexible token passing with wrapped tokens. We should frame it and treat it as a choice of message passing strategy that can be configured per Vault requirer, for both KV, PKI and any future secret engine.

[skatsaounis]

One thing I'm unsure of, but I don't have a strong opinion on (yet 😆 ) is whether we want to

1. Overload the response (i.e. it could return a wrapped token, or a secret ID in the same field).
2. Make that implicit on whether we have received a wrap_ttl or not.

I don't have any suggestions here, so maybe this is just noise, but I thought it was worth mentioning in case it sparks any discussion.

The way I see it is, passing secret-id's instead of secrets fulfills almost the same role as putting some response into a cubbyhole and passing a token for it. The main difference being the secure explicit granting mechanism with juju and the more flexible token passing with wrapped tokens. We should frame it and treat it as a choice of message passing strategy that can be configured per Vault requirer, for both KV, PKI and any future secret engine.

My initial approach on my local branch was to overload the role-secret-id. But then I found it misleading as the name promises something different than the content. But I am happy to proceed with whatever option you want me to. As the practitioner who needs to enable charmed MAAS integration with Vault I am more interested into enabling it rather than being strong opinionated with the final decision. Please let me know how to proceed. I then update my PRs and try to speed up things.

Overall, thank you very much for your involvement and your interest to discuss wrapping tokens :slightly_smiling_face:

[DanielArndt]

My initial approach on my local branch was to overload the role-secret-id

My bad, I thought that is how it was implemented, but I see now that isn't the case. That was the source of my question, so ignore the noise.