* [JENKINS-28071] generalise BuildCommand target from AbstractProject to Job

This allows e.g. WorkflowJob to build, fixing symptom [JENKINS-29826]

* fixup! [JENKINS-28071] generalise BuildCommand target from AbstractProject to Job

* fixup! [JENKINS-28071] generalise BuildCommand target from AbstractProject to Job

Re-factored all existed CLI code to follow the new proposed scheme for
raising an exception if issue occurs, handling and reporting it.
Unified CLIRegisterer as well.
Fixed unit tests to follow the new scheme.

In addition to cluttering the namespace, unused imports generate
compiler warnings, introducing noise and obscuring more important
compiler warnings.  This change removes them.

[FIXED JENKINS-15094] - Handle null parameter values in BuildCommand (CLI) and Parameter classes (CLI).

The change adds missing checks for null ParameterValue, which may be passed from the CLI.
It prevents the death of Jenkins executors during the canTake() check of node labels.
Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>

This behaviour is noted in MapOptionHandler.

New test in hudson/cli/BuildCommandTest.groovy, as well as companion
@TestExtension class, thanks to Jesse' suggestion. This is so that we
test this hereby fixed case of a QueueDecisionHandler Refusing a build,
leading to that null value now checked and handled accordingly.

Commit also includes sorted imports and a few minor indentation fixes,
as well as another (very) minor string change.

No test added in hudson/cli/BuildCommandTest.groovy, as this case is no
longer reproducible with bare Jenkins core and cli. Indeed, one now
need a plugin to extend QueueDecisionHandler, so it can Refuse a build,
hence test this specific null case. Regression tests do all pass still.

[FIXED JENKINS-19749] Add a -f option for following the build without passing interrupts through to the build

indicate failure.

unbuildable project.

Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.

This fix implements an optional retry loop for cli BuildCommand
The retry is not for the actual command, but for reading the log file
(when -v is used) This is so that slow machines, which may create the log
file so slowly that is it not present when reading of it starts,
will optionally  try to start reading it multiple times.

This is implemented via a use of an optional "-r INT" cmd option

Noticed via failure in BuildCommandTest.testConsoleOutput.
https://github.com/jenkinsci/jenkins/pull/522

Current CLI is always available and most commands can be run by anonymous users.
Now only a short help message and the login command are available for anonymous
in a Hudson without anonymous read permission, and each individual command also
checks the appropriate permission for that command.  Details:
* Vulnerable CLI commands now fixed:
  build, clear-queue, copy-job, create-job, delete-builds, delete-job,
  disable-job, enable-job, install-plugin, install-tool, keep-build,
  mail, restart, safe-restart, set-build-result
* Broken CLI commands now fixed:
  connect-node, delete-node, disconnect-node, offline-node, online-node
* Other vulnerable command (not CLI) now fixed: /gc (JVM garbage collect)


git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@33626 71c3de6d-444a-0410-be80-ed276b4c234a

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23699 71c3de6d-444a-0410-be80-ed276b4c234a

- introduced SimpleParameterDefinition to eliminate the common code

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23543 71c3de6d-444a-0410-be80-ed276b4c234a

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@23530 71c3de6d-444a-0410-be80-ed276b4c234a