Consider removing com.nimbusds:oauth2-oidc-sdk dependency

We should strongly consider removing the com.nimbusds:oauth2-oidc-sdk dependency as it has caused a number of issues over the years ever since we added it's usage in the OAuth2 support.

The root issue is the result of the out-of-sync release process used for the oauth2-oidc-sdk and nimbus-jose-jwt artifacts. Since oauth2-oidc-sdk depends on nimbus-jose-jwt, it's important to keep the versions of these artifacts in sync - only if oauth2-oidc-sdk is being used. However, there are cases where this poses to be a challenge, when artifacts are unexpectedly downgraded as described in this comment. As a result, we're also forced to downgrade versions to prevent dependency convergence, and this is not ideal as we should always strive to be using the latest versions as a best practice.

The support overhead that com.nimbusds:oauth2-oidc-sdk dependency has added over the years has outweighed the value of reuse of the library, so I recommend we remove the use of the library altogether and only depend on com.nimbusds:nimbus-jose-jwt and ensure we're always on the latest version.

We are currently using com.nimbusds:oauth2-oidc-sdk in the following classes:

• OAuth2ErrorResponseErrorHandler
• ClientRegistrations
• DefaultReactiveOAuth2UserService
• OAuth2AccessTokenResponseBodyExtractor

After reviewing the code in the above classes, I believe updating the code with our own implementation would be minimal effort and it ultimately would save us from any further support overhead.

Related gh-13843, gh-13990

Start by tracing the use of com.nimbusds:oauth2-oidc-sdk in OAuth2ErrorResponseErrorHandler, ClientRegistrations, DefaultReactiveOAuth2UserService, and OAuth2AccessTokenResponseBodyExtractor. Review the related issues and the existing nimbus-jose-jwt usage before assessing the replacement scope. Done means those classes no longer use oauth2-oidc-sdk and the project depends only on nimbus-jose-jwt for this support.