Add general purpose header support to RestTemplateBuilder

[L00kian]

See #17072 for details.

Added convenience methods for customising the RestTemplate built HttpHeaders handling. The #17010 approach was taken as a baseline. The underlying BasicAuthenticationClientHttpRequestFactory reworked to accept any number of HttpHeadersCustomizer instances to handle http request headers. Added convenience methods to RestTemplateBuilder to populate a 'default header' as well as custom HttpHeadersCustomizer implementations. Refactored #17010 changes to follow the same HttpHeadersCustomizer concept

[L00kian]

Hello,
I was trying to re-trigger the build as the failure doesn't seem to be related to the changes above. However I was unable to login into concourse using GitHub authentication. Clicking on Login button downloads empty 'callback.dms' file. Not sure if that's an expected behaviour as well as to whom to address it to. Still I think it worth mentioning

Thanks.

[ielatif]

https://ci.spring.io/builds/79665

[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] ReactiveElasticsearchRepositoriesAutoConfigurationTests ? ExceptionInInitializer
[ERROR] ReactiveRestClientAutoConfigurationTests ? ExceptionInInitializer
[INFO]
[ERROR] Tests run: 2185, Failures: 0, Errors: 2, Skipped: 11

You have to rebase against upstream master @wilkinsona has fixed this in #17092

[L00kian]

Yep, will do. However still curious about the CI login :)

[ielatif]

Yep, will do. However still curious about the CI login :)

Yep I am curious too :)

[wilkinsona]

It is intentional that you can't log in to Concourse. That's only needed for administrative purposes. AFAIK, adding commits or force-pushing should be sufficient to trigger a new build.

[philwebb]

Thanks for the PR @L00kian! This has now been merged into master.

Whilst working on the merge it hit me that we can generalize the customizer even more and one that applies to ClientHttpRequest rather than just the headers. I've done this in commit aad21d1. I've also made a small framework change that makes the "add a header if not already present" use-case much easier.

Thanks again for the contribution!

[L00kian]

Thanks!
Just curious why basic authentication needs a special case for itself. Is there any specific reason why it shouldn't be handled by a specific request customiser as well?

[philwebb]

@L00kian I started to get worried that users might call requestCustomizers and accidentally wipe out their basicAuth settings. In other words, the following would work:

builder.requestCustomizers(customizers).basicAuth("user", "password");

but this version would not:

builder.basicAuth("user", "password").requestCustomizers(customizers);

In the end I decided to make the basicAuth and defaultHeader stuff distinct from the requestCustomizers. The BasicAuthentication class itself could have been a RestTemplateRequestCustomizer, but since it's package private and only really needs the headers I just decided to call the applyTo method directly.