SOLR-16738: Refactor AdminHandlersProxy for better extensibility

[gerlowskija]

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

Description

AdminHandlersProxy, in its current form is unwieldy to extend to cover our v2 API:

• it relies on v1 GenericSolrRequest's to send requests
• it assumes a NamedList in several method signatures
• it relies on specific hard-coded params to trigger proxying
• it has a few hard-coded special-cases around "wt" values.

Ultimately, a big part of the problem here is that AdminHandlersProxy is a big static thing that gets used everywhere. As a result it's riddled with special cases to accommodate it's different callers.

Solution

This PR refactors AdminHandlersProxy by making it an abstract class that supports multiple implementations. Each implementation must support the following methods:

• boolean shouldProxy() - determine whether a given request needs proxying or not
• Collection<String> getDestinationNodes() - identify the node(s) that should be proxied to.
• SolrRequest<?> prepareProxiedRequest() - create a SolrRequest that can be sent to remote nodes
• void processProxiedResponse(String nodeName, NamedList<Object> proxiedResponse) - do something with the response of a proxied request.

(The NamedList in the last item above is unfortunate, but note that it's compatible with v2 implementations. See V2RequestProxy for more details.)

Three different AHP implementations are included in this PR to cover both v1 and v2 API requests:

• GenericV1RequestProxy
• V2SolrRequestBasedProxy
• a metrics-specific impl created anonymously in MetricsHandler

Other notable details include:

• creates a subpackage for proxy related classes: org.apache.solr.handler.admin.proxy
• renames AdminHandlersProxy to the more general (less-v1 specific) RemoteRequestProxy.

Tests

New unit tests for helper class WrappedSolrRequest in WrappedSolrRequestTest. Unit tests for new proxy subclasses in GenericV1RequestProxyTest and V2SolrRequestBasedProxyTest.

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, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added a changelog entry for my change

[janhoy]

Nice direction.

[igiguere]

I'm thinking that support for V2 would be easier if the response type, at least, was a type parameter:
AdminHandlersProxy<R> // R = response type: NamedList, or (extension of) SolrJerseyResponse, or InputStreamResponse (i.e.: metrics)
Then, we would have methods like:

• processProxiedResponse(String, R)
• callRemoteNode(String, SolrRequest<R>)
• ...
  That might leave a bit more implementation details to the classes extendingAdminHandlersProxy, but we would not have to worry about NamedList responses from V2.

[gerlowskija]

Hey all - I wanted to incorporate some of the advice that @igiguere gave above. Particularly around giving AdminHandlerProxy a type parameter that allows its methods to be a bit more tailored to the particular use-case. I think it worked out really nicely!

Slight bad news though - I wanted a fresh start as I was doing this and ultimately ended up using a new branch and force-pushing that here. Which will mangle some of the PR history and conversation-threads. Sorry about that - I should've found a better way.

In any case, I'll update the PR description above to better reflect the latest design. And I'm taking this out of "Draft" mode for now and will aim to merge later this week. Tests and check both pass.

[gerlowskija]

I can't think of any end-user impact here that'd merit a changelog. If anyone sees an aspect of this that I'm missing let me know, but otherwise I'm going to add the no-changelog label.