SOLR-17488: CLI: Resolve -d conflicts

[epugh]

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

Description

see jira

Solution

• Deprecate -d for server-dir in RunExmapleTool.
• Support --server-dir in bin/solr and bin/solr.cmd
• Deprecate -d for delay in PostTool to avoid any confusion with conf-dir.

Tests

bats and java tests

[epugh]

@malliaridis this is ready, I avoided deciding what to do about keep versus --delete-config since deciding that wasn't requried to resolve -d conflicts.

[malliaridis]

Thanks for creating a PR this quick. I have found a couple -d references, mainly in documentation, that need to be updated as well:

• bin/solr.cmd#408: IF "%1"=="--server-dir" goto set_server_dir should be included
• bin/solr.cmd#1522-1524 (around): In the code block only -d is checked, but --server-dir should be included as well probably
• bin/solr#1375: -d in error message should be --server-dir
• solr-control-script-reference.adoc#99: -d should be --server-dir
• solr-control-script-reference.adoc#110: -d should be --server-dir
• solr-control-script-reference.adoc#206: -d should be --server-dir
• solr-control-script-reference.adoc#281: -d should be --server-dir
• solr-control-script-reference.adoc#418: Is -d a valid option here?
• solr-control-script-reference.adoc#800: -deleteConfig should be --delete-config
• solr-control-script-reference.adoc#824: -deleteConfig should be --delete-config
• solr-control-script-reference.adoc#983: -d should be --server-dir
• post-tool.adoc#46: -d should be removed

[epugh]

Thanks for the additional review @malliaridis and I think I've got them sorted. I love how hte docs look with hte long form of the variables, much easier to read.

[malliaridis]

Is this code block still gonna work correctly if --server-dir and --solr-home is used instead?

I feel like we have to somehow get rid of these lists of options, they seem very error-prone and can be easily forgotten when we make changes.

[epugh]

Yeah, good darn question. I also think we have extra options parsing in the .cmd that doesn't exist in bin/solr... I think we have places where we could be leaning more on the existing java parsing...

[epugh]

I opened this: #2760