SOLR-17300: Copy existing listeners on re-creation of Http2SolrClient

[iamsanjay]

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

Instead of #2462, this PR would copy the existing listeners to the new Http2SolrClient. This way re-creating client not requires to call explicitly Builder#withListenerFactory to copy existing listeners as withHttpClient method automatically takes care of that.

Added #2462 test case here.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[dsmiley]

Proposed CHANGES.txt under improvements:

SOLR-17300: Http2SolrClient.Builder.withHttpClient now copies HttpListenerFactory (e.g. for auth, metrics, traces, etc.)

[dsmiley]

will the test do its job with one node? If so, reduce resources to help make our tests faster.

[iamsanjay]

Yes one node will do. +1 to reduce resources!

[epugh]

Someday in dev-docs, we ought to have "The list of things @dsmiley looks for when writing tests" ;-)

[dsmiley]

Hmmm TestInterleavingTransformer failed and it isn't a flapper:

[iamsanjay]

Hmmm TestInterleavingTransformer failed and it isn't a flapper:

Yup it's new. But ran successfully on my machine, tried multiple times now. Should we consider enabling the re-running failing test strategy, or I do not know If it's enabled already or not, to check whether it's flaky or not? https://docs.gradle.com/develocity/flaky-test-detection/

Evidence To further support it:

Flaky Tests at Google and How We Mitigate Them

We even have a way to denote a test as flaky - causing it to report a failure only if it fails 3 times in a row. This reduces false positives, but encourages developers to ignore flakiness in their own tests unless their tests start failing 3 times in a row, which is hardly a perfect solution

Cost of Flaky Tests in CI: An Industrial Case Study

Automatically rerunning a test costs 0.02~cents, while not rerunning and thus letting the pipeline fail results in a manual investigation costing $5.67 in our context. The insights gained from our case study have led to the decision to shift effort from investigation and repair to automatically rerunning tests

[dsmiley]

Flaky test detection & running a failing test again is a topic that should be brought to the dev list. I'd absolutely love to see that be worked on! Would probably start with us using https://github.com/gradle/test-retry-gradle-plugin which is referred to by GE.

You should trigger a re-run of the failed build; it doesn't take long for Crave's 96-core beast to run all tests.

Any way, +1 for you to merge with your newfound privileges to do so. Take care to edit the commit message to clean it up. I like to take the CHANGES.txt text and paste it in and maybe edit it a bit, and then add further detail if warranted (e.g. why you deprecated something).

If you don't have privileges to do these things then you have yet to complete your onboarding instructions involving GitHub.