SOLR-599 New Solr Client Using Java 11+ java.net.http.HttpClient

[jdyer1]

https://issues.apache.org/jira/browse/SOLR-599

This PR adds HttpSolrClientJdkImpl, a Solr client using the built-in Java 11+ Http Client rather than an external dependency. This is intended to be a drop-in replacement for Http2SolrClient and/or HttpSolrClient for client applications running either Http/1.1 or Http/2. This is not intended for Solr's server-side inter-node requests. This new client is aimed at those users wishing to reduce transitive dependencies in their applications.

This PR factors out a new abstract superclass, Http2SolrClientBase, from which both Http2SolrClient and HttpSolrClientJdkImpl extend. A similar refactoring is made to the corresponding unit tests.

Should it be desirable to include this new client in a future SolrJ release, a possible follow-up would be to split the SolrJ artifact. A "core" artifact could be published having fewer transitive dependencies with additional artifacts per client library dependency. This would allow downstream applications to include only those transitive dependencies they need, without resorting to build tool exclusion mechanisms.

Although I am including this as a potential solution for SOLR-599, this client is only "lightweight" in the sense it does not require additional client dependencies. This client is intended to support most features included with the existing clients.

There is one TODO in the HttpSolrClientJdkImpl to possibly find a more memory-efficient way to handle POST requests. There is a NOCOMMIT in solr-tests.policy. I could not figure out how to properly set the permissions for java.net.URLPermission, resorting to AllPermission for the time being.

[janhoy]

This is so cool! Let’s make it the new default client in a solrj-core artifact?

[jdyer1]

I am reminded here that we have a NOCOMMIT in solr-tests.policy. I am worried here that the only way to properly set the java.net.URLPermission is to enumerate all possible URL's (with ports) that might be hit during the test. In this case, we might need to generate the policy file in the @beforeClass method. I am hoping someone can suggest something easier!

[jdyer1]

Today I did my best in covering all the possible security manager permissions in solr-tests.policy. The NOCOMIT with the "all permission" is gone. I will be surprised though once we have CI runs with this if we do not see failures due to the policy file not handling some other variation of "localhost".

Besides this, I will try to write something up for the reference guide and then if there are no objections I would like to merge this to main soon, and ?perhaps maybe to branch_9x as well?

[dsmiley]

@jdyer1 Lets use a PR to collaborate on workaroundToReleaseThreads_noClosableUntilJava21. Getting all threads and interrupting each is a hack I'd like to try and avoid. I don't recall any test doing that despite us having a crazy number of tests.

[dsmiley]

Instead of simply interrupting the threads, shouldn't we also join on them? Should that be in an AfterClass -- is it a problem between each test? note: you don't need to gather a Set to then iterate; you can call forEach on the stream to do whatever you want to do. I don't think using a Set (for uniqueness) is necessary here either. What is the GC accomplishing?

I was looking again at all those test overrides that call super. I removed them locally and I was able to run at the CLI and IntelliJ and it ran all the intherited tests. This pattern is done elsewhere like SolrExampleTests