Revert resource management changes in RestTemplate

[bclozel]

Changes introduced in #29010 are not bringing the expected improvements to the API.
The request factories can still be externally managed or automatically created when RestTemplate is instantiated. This imbalance leads to compiler warnings for perfectly valid use cases.

Introducing more changes to the RestTemplate API is not warranted at this stage, so we've decided to revert this change altogether and accept this limitation.

[lenin-jaganathan]

@bclozel I ended up here looking for a solution to make ClientHttpRequestFactory closeable.

My requirement is kind of close to a RestClient during the application lifecycle, and create a new one if some of the configuration properties change (or certificate changes). What I noticed was that dereferencing ClientHttpRequestFactory might not be enough to close the underlying resources. What would be your suggestion for such use cases?

[bclozel]

@lenin-jaganathan I don't have much here unfortunately.
This issue was an attempt to solve this problem but this didn't work because it broke a lot of existing integrations. The best you can do is keep a reference to the ClientHttpRequestFactory and destroy it manually if it implements DisposableBean.

We might revisit this in the future when we'll remove RestTemplate.

[lenin-jaganathan]

That is what we currently do to close/destroy/stop if any of these are implementations of those interfaces. Seems like JDKClient doesn't implement any of these. For now, I will raise a issue/PR for atleast having the ClientHttpFactory implementations do such cleanups. Some of them do while some don't even when the underlying client does it.

[bclozel]

@lenin-jaganathan can you please create an issue instead? I'll discuss that with the team. The DisposableBean contract on request factories mostly dates back to the XML days. I think we need a global strategy to improve the situation.