Add oauth library

[nsklikas]

Adds the library implementing https://github.com/canonical/charm-relation-interfaces/blob/main/interfaces/oauth/v0/README.md

TODO:

• Add ca_chain to relation (Will be done in future PR)
• More tests?
• Do we want integration tests (Will be done in future PR)

[nsklikas]

There are some features missing from the current implementation, but I think it's best to add them in separate PRs in order not to overload this one:

• Currently traefik does not pass its ca_chain from the relation interface, making it impossible to get the ca_chain. We will add that feature in the future.
• When the relation is broken, the client should be deleted. This is not handled right now, as when we get the relation broken event we have no way of knowing which client we must delete. I think the most common solution to such a problem would be to use the peer relation to store a mapping from relation_id to client_id (@gruyaume any thoughts on this?).

[massigori]

Currently traefik does not pass its ca_chain from the relation interface, making it impossible to get the ca_chain. We will add that feature in the future.

I agree, let's keep this as a separate PR

[nsklikas]

On the requirer side do we want to emit an event once the relation is broken or are the charms expected to handle that on their own?

[gruyaume]

There are some features missing from the current implementation, but I think it's best to add them in separate PRs in order not to overload this one:

• Currently traefik does not pass its ca_chain from the relation interface, making it impossible to get the ca_chain. We will add that feature in the future.
• When the relation is broken, the client should be deleted. This is not handled right now, as when we get the relation broken event we have no way of knowing which client we must delete. I think the most common solution to such a problem would be to use the peer relation to store a mapping from relation_id to client_id (@gruyaume any thoughts on this?).

• It's fine not to add "everything" from a feature in a PR, as long as the code in the PR does what it's supposed to do and doesn't break the current behaviors. Make sure you have a user story that covers the changes that weren't included here. Either your current user story or a new one.
• The question of the relation broken is a good one. I'm not a fan of having to maintain a mapping like this one and would avoid it if possible. In hydra when we create a client, we can choose its ID right? Can't we write a semantic ID based on the relation ID (and other stuff if necessary)?

[nsklikas]

* The question of the relation broken is a good one. I'm not a fan of having to maintain a mapping like this one and would avoid it if possible. In `hydra` when we create a client, we can choose its ID right? Can't we write a semantic ID based on the relation ID (and other stuff if necessary)?

Unfortunately, there is no way in hydra to choose the client_id. The reasoning behind it is that they create client_ids using some hash function to optimize SQL queries for deployments with millions (?) of clients. I tried to think of a way to avoid having to use the peer relation but I don't think we can (we could do a full diff, ie check the relations and compare them with the clients in the database, but that seems way worse).

[nsklikas]

I tried to refactor the tests and improve their naming. Please have another go at reviewing it.

[gruyaume]

Good job on the unit tests, they look much cleaner. I just gave 1 comment on coupling

[gruyaume]

Good job!