feat: Migrate to HttpClient5 in OAuth2Service

[Jonas-Isr]

Context

https://github.com/SAP/ai-sdk-java-backlog/issues/328

This PR migrates the OAuth2Service to use HttpClient5 internally. In order to do this, the new class HttpClient5OAuth2TokenService is introduced (and tested) in place of the previously used com.sap.cloud.security.xsuaa.client.DefaultOAuth2TokenService which relies on HttpClient4.

Feature scope:

• Implement HttpClient5OAuth2TokenService
• Test HttpClient5OAuth2TokenService
• Test usage of HttpClient5OAuth2TokenService

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Documentation updated
• Release notes updated

[Jonas-Isr]

We could maybe remove some if these first tests of createHttpClient. But technically they all test different behaviours.

[CharlesDuboisSAP]

Why not put your new HttpClient5OAuth2TokenService in the security library? They might have more tests to make sure it works.

[Jonas-Isr]

Why not put your new HttpClient5OAuth2TokenService in the security library? They might have more tests to make sure it works.

The security library apparently is planning to release a similar feature in the future. Since it is not sure when this will be released and in what capacity (minor/major version release etc), it makes more sense to continue with our effort here.

[newtork]

Why not put your new HttpClient5OAuth2TokenService in the security library? They might have more tests to make sure it works.

The security library apparently is planning to release a similar feature in the future. Since it is not sure when this will be released and in what capacity (minor/major version release etc), it makes more sense to continue with our effort here.

Unfortunately even if get it into their code-base, we couldn't directly use it. Because we would depend on a latest version, whereas our users may provide an older version of the security-library - that could result to dependency version mismatch and missing method runtime exceptions.

We already made the painful mistake in the past, and we had discussions with users complaining that the SDK stopped working for them. Unfortunately there is no static code check that would check for such breaking changes. I guess library development is a little special in this regard.

Technically we are required to check for every external API usage what's the minimum dependency version (major and minor). That hopefully explains why (we want to) put @since javadoc tags on every of our public APIs. It helps the consumer.