XmlBasedHttpClientProvider in Jetty 10

[sbordet]

XmlBasedHttpClientProvider is loaded via reflection by HttpClientProvider (only usage).
HttpClientProvider is unused.
DefaultHttpClientProvider is only used by HttpClientProvider, which is unused.

@lachlan-roberts I guess all those classes were an attempt to allow applications to provide their own, custom, HttpClient instance to be used in WebSocket.
If this mechanism is present but implemented differently in Jetty 10, then those classes should be removed.

Otherwise a similar mechanism should be provided, based on ServiceLoader rather than reflection.

@joakime other inputs?

[lachlan-roberts]

We create the HttpClient at only one place, in the WebSocketCoreClient constructor if we were not given a HttpClient.
https://github.com/eclipse/jetty.project/blob/477d7cf1da534ecfb5c1087cdbc445adb4028e7f/jetty-websocket/websocket-core/src/main/java/org/eclipse/jetty/websocket/core/client/WebSocketCoreClient.java#L62-L70

Using the HttpClientProvider here would work for the javax client side because it is only created with the default constructor, however on the server side we first search for a HttpClient as attributes on the ServletContext and on the Server, so it would use the HttpClientProvider only if it did not find a HttpClient here first.

Also XmlBasedHttpClientProvider currently lives in jetty-websocket-client, but we would need to bring it into websocket-core to use it in the WebSocketCoreClient.