Remove HttpClientConfig in favor of ResourceRetriever Bean

[rwinch]

Summary

Rather than having HttpClientConfig replace it with allowing the user to provide a ResourceRetriever Bean which would override the default. Users wishing to change the timeout could then provide a DefaultResourceRetriever Bean with a different timeout.

This removes configuration specific code and provides more flexibility by allowing the ResourceRetriever that is used to be replaced with a different implementation.

Related #4477

[jgrandja]

ResourceRetriever is used by RemoteJWKSet in NimbusJwtDecoderJwkSupport when fetching the JWK Set Uri. However, ResourceRetriever is not used for the TokenRequest in NimbusAuthorizationCodeTokenExchanger nor is it used when fetching the UserInfoRequest in NimbusOAuth2UserService.

This is the reason I decided to create HttpClientConfig so it can be used consistently across these 3 use cases and future use cases for outbound requests. Does this make sense or do you have another suggestion?

[rwinch]

I don't like having configuration directly in our service layer. Configuration belongs in the configuration. Perhaps we need to introduce an abstraction for retrieving resources / HTTPRequest that can unify the settings. That implementation can delegate to the original methods with the proper settings

[jgrandja]

Ok let me see what I can come up with.

[jgrandja]

@rwinch I removed HttpClientConfig and set the default read and connection timeouts to 30 secs for all 3 client calls in NimbusAuthorizationCodeTokenExchanger, NimbusOAuth2UserService and NimbusJwtDecoderJwkSupport.

Let's revisit the client abstraction for retrieving resources after we go GA.

I'll leave this issue open.

[rwinch]

Closing since HttpClientConfig has been removed and this is now invalid