SOLR-16458: Node system info V2 api jersey resource

[igiguere]

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

Jira Ticket

The Excel spreadsheet links to SOLR-16458 for the V1 /solr/admin/info/system and V2 /api/node/system, although the ticket does not mention those URLs.

From the checklist below : "I have created a Jira issue and added the issue ID to my pull request title." - m'well, no. But keeping track of these V2 tickets is probably difficult enough without adding one more.

Sorry about the mix-up in the commit messages. I originally landed on the wrong ticket.

Description

Implementation of a Jersey resource to support getting the system info. This new resource should replace the home-brew "Endpoint" V2 resource.

DRAFT:

• Should we keep the URL path /node/system as suggested in the Excel spreadsheet? This PR suggests /node/info/system. If we keep the same URL path as the "old" V2, then the home-brew "Endpoint" will be deleted.
• AdminHandlersProxy does not support V2, so this PR does not test parameter "nodes". Ref: PR SOLR-16738: Refactor special-casing out of AdminHandlersProxy  #3991, mentioned in PR SOLR-17436: Create a v2 equivalent for /admin/metrics #4057
• I didn't like that the system info returned in the single-node response was not separate from the response header (i.e.: fields "node"(name), "mode", "core_root"... at the same level as "responseHeader").
  -- This PR wrap the system info in "nodeInfo":
  <response>
<lst name="responseHeader"><!-- ... --></lst>
<lst name="nodeInfo">
<str name="node">localhost:8983_solr</str>
<!-- ... -->
</lst>
</response>
  -- Ideally, IMHO, the "node" field should be named "name" (i.e.: the node name), and then the wrapper "nodeInfo" could be just "node"
  -- AdminHandlersProxy wraps all proxied responses into a NamedList where the name is the node name (host:port_solr). This creates a structure with unpredictable (or not easily predictable) keys. If we do adopt a response with the "nodeInfo" wrapper, then, the proxied responses could be added to the list of "nodeInfo"... In a specific implementation of AdminHandlersProxy (ref.SOLR-16738: Refactor special-casing out of AdminHandlersProxy  #3991). This is all a lot of changes, breaking changes for whoever is parsing the response already. Opinions?
• TODO: Clean-up documentation. Path /admin/info/system is mentionned in 5 pages... And there's SOLR-11918 ?

Solution

Add NodeSystemInfoApi (in solr-api), implemented in GetNodeSystemInfo.

Class NodeSystemInfoProvider contains code to provide the system info, copied from SystemInfoHandler.

Clean-up SystemInfoHandler to use GetNodeSystemInfo.

Tests

Add unit tests for NodeSystemInfoProvider (note that the test class for SystemInfoHandler was actually only testing a method now found in NodeSystemInfoProvider).

Add unit tests for GetNodeSystemInfo.

Functional tests on a local instance (dev-slim, started with the "cloud" example)

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 documentation for the Reference Guide
• I have added a changelog entry for my change