(cherry picked from commit f4ddac10)

(cherry picked from commit 3c4b1e63)

(cherry picked from commit 4e2efcda)

(cherry picked from commit 37167d5f)

(cherry picked from commit 8dd079a8)

(cherry picked from commit 33923db1)

(cherry picked from commit c4c72598)

(cherry picked from commit 8f1883a0)

Besides failing in master, it also fails in 4e0af431 (merge of #1443), but passes in the 1.598-SNAPSHOT parent 239caf89.
(cherry picked from commit 33041903)

Use kind when descriptor.id != descriptor.clazz.name and $clazz otherwise.
(cherry picked from commit 901194ae)

to lookup descriptor by id or by Describable class name
(cherry picked from commit 6a8ce6ca)

to match some specific use cases.

(cherry picked from commit 8881703f)

(cherry picked from commit 86bac90f)

(cherry picked from commit 7514e8c6)

[FIXED JENKINS-27708][FIXED JENKINS-27871]  Ensure that identification of blocked tasks is using the live state.

- The creation of a snapshot itself should be relatively cheap given the expected rate of
  job execution. You probably would need 100's of jobs starting execution every iteration
  of maintain() before this could even start to become an issue and likely the calculation
  of isBuildBlocked(p) will become a bottleneck before updateSnapshot() will. Additionally
  since the snapshot itself only ever has at most one reference originating outside of the stack
  it should remain in the eden space and thus be cheap to GC.

- JENKINS-27708 comments 225819 and 225906 provide more complex but logically equivalent fixes of
  this issue. I am favouring this approach as it is simpler and provides less scope for error as any
  new helper methods can just rely on the snapshot being up to date whereas with the other
  two candidates if a new helper method is introduced there is the potential to miss adding support
  for the live view. The comment 225819 has the risk of introducing extra lock contention while
  the comment 225906 version forces every access to the helper methods to pass a second memory
  barrier

(cherry picked from commit 5880ed83)

(cherry picked from commit f6454983)

[FIXED JENKINS-28062] A Launcher.afterDisconnect() method that propagates an exception is a sign of a bad Launcher not a problem closing the channel.

(cherry picked from commit d760216d)

```
WARNING: Caught exception evaluating: executor.progress in /ajaxExecutors. Reason: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
...
	at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.ArithmeticException: / by zero
	at hudson.model.Executor.getProgress(Executor.java:649)
	... 154 more
```
(cherry picked from commit e685b604)

(cherry picked from commit 6528ff1e)

(cherry picked from commit dab56506)

(cherry picked from commit e5e53be0)

(cherry picked from commit 9afb092b)

(cherry picked from commit cb174607)

(cherry picked from commit 44db6aef)

(cherry picked from commit c51fd534)

[JENKINS-26520] Documentation fix for $BUILD_ID

prevent removing artifact when build isn’t completed yet

Without this change you need to do:

```
User user;
final SecurityContext oldContext = ACL.impersonate(a);
try {
    user = User.current();
} finally {
    SecurityContextHolder.setContext(oldContext);
}
```

Which seems incredibly wasteful.

Or else you need to replicate the logic in User.current() which makes that code hard to change.