Enable picocli for a few tools

[janhoy]

PR that will merge into the Picocli feature branch visualized by #3254. This PR adds:

• Parses bin/solr with picocli by default but also retain commons-cli for comparison. Switch using SOLR_PICOCLI=false
• Implements VersionTool, HealthcheckTool and StatusTool as sub commands
• New ZkTool sub command, which in turn has ZkLsTool as a sub command
• Demonstrate use of custom defaultValueProvider to let --zk-host option look for a value in environment

This is the first of many PRs to go against the feature branch to try to build full picocli coverage for the CLI tools.

Sample output for bin/solr -h:

Usage: solr [-hv] [COMMAND]
Global options:
  -h, --help      Display this help message
  -v, --version   Print version information and exit

Commands:
  status       Get the status of a Solr server.
  healthcheck  Check the health of a SolrCloud collection.
  version      Prints the Solr version.
  zk           Sub commands for working with ZooKeeper.

SolrCloud example (embedded Zookeeper):

  ./solr start -c

For more help on how to use Solr, head to https://solr.apache.org/

[epugh]

This looks super interesting! I briefly looked at Picocli based on @janhoy input back when we started revamping the cli in 2024, but it felt a step too far, so we focused on just getting all our args reworked.

Now, I think that picocli brings a lot of great features. One that I am quite intrigued by is generating docs for our CLI in AsciiDoc: https://picocli.info/#_generate_man_page_documentation, I took a stab at generating docs from commons-cli, but it was too hard. Plus the support for sub commands looks interesting... I think this is a really good direction...

[epugh]

i wonder if we should have a more generic abstraction that isn't tied to "zkHost" for detecting if we are in solr cloud mode? Maybe an explicit method, because I feel like we are slowly hiding zkHost more and more, and the client may just be a solrClient configured with a solrUrl. <-- this isn't specific to your picocli change I know!

[janhoy]

Eric, you have really lifted the CLI in the last versions, none of which is wasted if/when moving to picocli!

Also, we have pretty good test coverage in bats tests, which is a great way to validate parity. It's not a goal to retain the exact same help/usage output. Let the tool generate based on best practices. However, given a CLI invocation MYENV=123 bin/solr foo --bar baz it should result in the same tool behavior as before. It could be a 10.0 only or also a 9.x feature depending on whether we feel that tool usage output is part of our back-compat guarantees. Perhaps 10.0 is safest, although backporting CLI bugfixes will be harder if 9x is still on commons-cli.

I'd be interested in chipping away on this in a central collaborative feature branch over the course of a several weeks..

[epugh]

Eric, you have really lifted the CLI in the last versions, none of which is wasted if/when moving to picocli!

Also, we have pretty good test coverage in bats tests, which is a great way to validate parity. It's not a goal to retain the exact same help/usage output. Let the tool generate based on best practices. However, given a CLI invocation MYENV=123 bin/solr foo --bar baz it should result in the same tool behavior as before. It could be a 10.0 only or also a 9.x feature depending on whether we feel that tool usage output is part of our back-compat guarantees. Perhaps 10.0 is safest, although backporting CLI bugfixes will be harder if 9x is still on commons-cli.

I'd be interested in chipping away on this in a central collaborative feature branch over the course of a several weeks..

I'd love to work with you on this... I lean towards this being a 10x feature, just so we don't have to backport, and we have some time to make it "perfect". I think CLI bugfixes on 9x will just being and end on 9x branch in this case.

So what is next? A branch in the main asf repo? Or do we just push to this one?

[janhoy]

I made a JIRA and a feature branch with only the gradle stuff.
Re-purposed this PR to add the first few tools as a POC.
More PRs should follow targeting that branch.

To see status of the overall feature branch, I made a draft PR #3254