Migrate to Apache HttpComponents HttpClient and HttpCore 5

[garydgregory]

Migrate to Apache HttpComponents HttpClient and HttpCore 5.

[jamesbognar]

Hi Gary,

There's changes I'd like to merge here, but some of it conflicts with how the Juneau client stack is laid out.

• juneau-rest-client-apache-httpclient-45: the next-gen client's transports are meant to be one module per backend, and HttpClient 5 is already covered by juneau-rest-client-apache-httpclient-50. Porting -45 to HC5 while keeping its artifact and class names would give us two HC5 transports, leave nothing for HC 4.5, and make the artifact name misleading. If we decide to drop HC 4.5 support, I think the right move is to remove the module rather than rename what's inside it. Happy to discuss that on dev@.
• juneau-rest-client-classic / juneau-rest-common-classic: these exist to give 9.x users source compatibility with their org.apache.http code. Moving them to HC5 removes a large part of that API (HttpClient interface methods, StatusLine, HeaderElement, HttpRequestRetryHandler, Header-typed entity getters, etc.). At that point users would have to rewrite anyway, and they'd be better off on the next-gen client. So classic stays on 4.5.

Two pieces were independent and good, so I've pulled them into #432:

1. Managing the HttpClient 5 / HttpCore 5 versions in the root pom (with httpcore5 kept at 5.4.3 to match what httpclient5 5.6.4 is built against).
2. The CloseMode.IMMEDIATE fix for SSE responses in ApacheHc5Transport, with a regression test.

Let me know if you think we should invest in a classic client on HttpClient/Core 5.

[garydgregory]

Hi James,

My main concern here was only to move off of the HC 4.x stack, which I don't plan on using with Juneau. Classic vs. Asynchronous is not something I am worried about ATM.

[jamesbognar]

@garydgregory - Gotcha. Yea we will be doing that by shipping the classic client as deprecated and removed in a future release. The next-gen clients that abstracts the client engine allows us to support any underlying client.

[garydgregory]

Hi @jamesbognar
So are you saying I should resolve the current conflicts and we'll be good to go?

[jamesbognar]

@garydgregory - No, you can close this PR. I've created a separate PR with your changes that are still relevant: #432

[garydgregory]

@jamesbognar
Hm, ok. I wonder why I had to edit so many more files (~200). Has the code been completely refactored?

[jamesbognar]

@garydgregory - Yea, the client-side code has been heavily refactored in 10.0.

[garydgregory]

@jamesbognar OK, closing.