Functionality was moved to OnlineNodeCommand class already

- Code that is running from a plugin and on the master's JVM is guaranteed to never get null from this method (any cases where you do get null are bugs in core)
- Code that is running from a plugin and on a remote JVM should never be allowed to load the Jenkins class in their classloader, so should never use Jenkins.getInstance()... we are annotating the method with @Nullable so that such code can have some evolution time
- Code that is running in core and on one of two special paths should use the Jenkins.getInstanceOrNull() method so that the UI can be presented to users before the singleton has been instantiated / after the singleton has been destroyed
- The remaining 95% of uses in core (and 100% of uses in plugins) can safely assume that the instance is never null

This reverts commit bb7c8fce.

Closes #2090, I'll redo this as a PR... though if that PR is subject to multiple rounds of review before being merged then I will take that of evidence of the exact problem that committing directly was supposed to resolve... namely exponentially multiplying the effort required to make actual improvements to the code base.

- It is never too late to do the right thing.
- The vast majority of usages of `Jenkins.getInstance()` in core currently assume that its return value is non-null
- This commit changes those that are written to correctly check for non-null values will call `Jenkins.getInstanceOrNull()`
- We deprecate the `Jenkins.getActiveInstance()` madness
- I checked with @kohsuke who said not to bother with a PR and just commit this strongly opinionated change direct to master as a PR will just degrade into a bikeshedding.

Computer.CREATE should be scoped to JENKINS, not COMPUTER, since it is checked on Jenkins, not a Node or Computer.
Compare Item.CREATE, scoped to ITEM_GROUP, not ITEM.

This change adds code to check that the user isn't attempting to rename
an existing node with the name of another existing node.  Previous to
this change, such rename operations would succeed and would corrupt node
configuration data.

(cherry picked from commit 16d6429c)

This change adds code to check that the user isn't attempting to rename
an existing node with the name of another existing node.  Previous to
this change, such rename operations would succeed and would corrupt node
configuration data.

online-node covered by test-cases

- Also tidy up some of the mess logic in both #1866 and #1860

(cherry picked from commit d72d7b83)

Node objects are owned by the Nodes class not by Jenkins so NodeProperties
and anything modifiying them needs to be updated.  Also modifying Nodes
requires a lock on the Queue so use this lock not Jenkins to prevent the
deadlock observed in JENKINS-30057

(cherry picked from commit 06f690db)

Node objects are owned by the Nodes class not by Jenkins so NodeProperties
and anything modifiying them needs to be updated.  Also modifying Nodes
requires a lock on the Queue so use this lock not Jenkins to prevent the
deadlock observed in JENKINS-30057

few chances there’s another implementation
but if one exists Function.isWindows would probably be wrong implementation

- Logging added to help diagnose was actually causing Jenkins.class to be initialized on the remoting side

(cherry picked from commit df831325)

More fun here:

- All this originates from Executor extending Thread.
- There is funky logic in the lock handling code of the JVM that makes assumptions
  about how it might proceed with the lock when the thread holding the lock has its
  interrupt flag set.
- Really it would be better if Executor did not extend Thread as that way we wouldn't
  have to deal with some of that complexity. But OTOH we are where we are and backwards
  compatibility may make such a change not possible without a lot of breakage.
- Fixing the issue at hand, firstly requires that interrupting a Computer happens with the
  Queue lock held (to speed up tests we have Jenkins.cleanup get the lock for all Computers)
  That prevents the Queue maintain thread from getting caught
- Secondly, when removing an executor from a computer we process the removal while
  holding the Queue lock, but we move the removal itself to a separate thread if we cannot
  get the Queue lock in order to avoid deadlock.
- Also add helper methods to wrap tasks to be performed while holding the lock
  and a helper method for Runnables that exposes the tryLock functionality

(cherry picked from commit 6f343dc7)

More fun here:

- All this originates from Executor extending Thread.
- There is funky logic in the lock handling code of the JVM that makes assumptions
  about how it might proceed with the lock when the thread holding the lock has its
  interrupt flag set.
- Really it would be better if Executor did not extend Thread as that way we wouldn't
  have to deal with some of that complexity. But OTOH we are where we are and backwards
  compatibility may make such a change not possible without a lot of breakage.
- Fixing the issue at hand, firstly requires that interrupting a Computer happens with the
  Queue lock held (to speed up tests we have Jenkins.cleanup get the lock for all Computers)
  That prevents the Queue maintain thread from getting caught
- Secondly, when removing an executor from a computer we process the removal while
  holding the Queue lock, but we move the removal itself to a separate thread if we cannot
  get the Queue lock in order to avoid deadlock.
- Also add helper methods to wrap tasks to be performed while holding the lock
  and a helper method for Runnables that exposes the tryLock functionality

(cherry picked from commit c6d4204a)

(cherry picked from commit c569036f)

Sometimes observed at end of (passing) WorkflowTest.executorStepRestart in 1.596.1:
Exception in thread "Executor #0 for slave0 : executing PlaceholderExecutable:job/demo/1/:null" java.lang.NullPointerException
	at hudson.model.Computer.removeExecutor(Computer.java:869)
	at hudson.model.Executor.run(Executor.java:272)

- Logging added to help diagnose was actually causing Jenkins.class to be initialized on the remoting side

Ensure that listeners do not get notified when a computer is killed from a thread with the Queue lock

- We don't know what those listeners will be doing
- I'm not completely happy with having to do it this way, there are some theoretical paths where we end
  up re-acquiring the Queue lock in Computer.kill() but they should not be the normal path