- JENKINS-15355
- JENKINS-21618
- JENKINS-22941
- JENKINS-25938
- JENKINS-26391
- JENKINS-26900
- JENKINS-27476
- JENKINS-27563
- JENKINS-27564
- JENKINS-27565
- JENKINS-27566

- Fixing link text for JENKINS-6167

Remove editorconfig

simplify displaying the executors

fix the @since tags

[JENKINS-27565] Fix threading issues with Nodes and Queue

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

API improvements around Executor/Executable

Additional change suggestions on top of PR 1610

IIUC, the expectation here is that Queue.Executable will instantiate AsynchronousException as a handle, start something asynchronously (say send a JMS message) with a callback, and the callback will tickle AsynchronousException.

So AsynchronousException might complete before it gets its executor set. This code change ensures that that case gets handled correctly.

Update the retention strategies... the JSR 305 annotations do not seem to be spec'd to apply to child methods also... bold poorly spec'd annotations

Remove `jenkins.setNodes(jenkins.getNodes())` style hacks to force the master number of executors to be updated

- We will never mind that this is probably the wrong import to use as Jenkins core is consistently using the
  wrong one (If anyone asks, for a `javax` import to be correct, it should have a JSR that has passed through voting
  and not have a JSR that is still subject to change... OTOH one could argue that if the JSR 305 should ever
  become revived from its current dormant state *and* it is decided to include in the JRE *then* the packages
  would get moved out of `javax` and into `java` so they are not in final form anyway... but that pre-supposes
  that the process of standardization does not modify the annotations and by virtue of being in `javax`
  there will be some special case handling by some classloaders which is why depending on the JSR305 versions
  is, in my view, a bad plan... anyway this is moot... Jenkins core is going with JSR305 as it currently stands
  so we call all go down together!)