Enhance OIDC Client to support the token revocation

[sberyozkin]

Fixes #26867

Keeping this PR as a draft until I figure out how to test it.

I just had to refactor OidcClientImpl a little bit to reuse the code which is used to post a request.

quarkus-oidc may also support it in the next phase (ex, to revoke the failed bearer tokens, on local logouts, etc).

CC @FroMage, FYI, OidcClient can also be configured to talk to Apple OIDC

[sberyozkin]

@pedroigor Have a look please when you get a chance. The main initial use case is for users of Keycloak (and other providers which support the revocation) be able to proactively revoke a given access token without going the whole refresh process, and for some providers it can be the only option if no RT is available.
But this is only the first phase. As far as OIDC client is concerned, we might consider adding another method to revoke both access and refresh tokens which would also require passing a token hint.
I'd also be interested in expanding it to quarkus-oidc (revoke the invalid bearer tokens proactively, or the tokens after the local logout and for some other cases).
I've been thinking for a while what to return, Boolean seems reasonable as 200 is expected from Keycloak if the token has been revoked or already been invalidated, while 503 seems mostly a theoretical case, and I don't really expect OidcClient then keeping retrying it, for example, for another 3 mins, etc, if really really necessary then the revocation can be retried at the application level with some configured reasonable retry period. It is just that kind of operation which does not seem worth retrying a lot, and should be tried as a single, best effort attempt to help OIDC servers to remove the tokens.

[pedroigor]

@sberyozkin Yeah, it should be useful for those looking for revoking the AT. You did almost everything to enable RT too :)

[sberyozkin]

Thanks @pedroigor, let me resolve the conflict and rebuild

[sberyozkin]

During the rebase I lost the code moved in the original PR from OidcClientRecorder to OidcClientImpl (related to the client secret post auth) which is what was causing a test failure

[sberyozkin]

Hmm...

[sberyozkin]

This test (oidc-client-wiremock) is passing all the time for me, it feels like KC 19.0.1 might not be removing some state in time between the tests, as I also some some unexpected test failures in one of the other PRs, for the moment it is not easy to pinpoint...