This implementation does not create new methods in API, hence it can be backported.

(cherry picked from commit 294ce778)

(cherry picked from commit 43b06626)

Just to prevent similar misuses in the future.

(cherry picked from commit 298e3713)

(cherry picked from commit 35eb8ac9)

The contract for JnlpAgentReceiver in case of error on a claimed node is
to call handshake.error() but still return true so other handlers don't
take another crack a it.

Also added unit tests DefaultJnlpSlaveReceiver.

(cherry picked from commit 2d452b6e)

(cherry picked from commit f7c0a49b)

In e91782e7 some help files were removed
from core because they were moved to LDAP plugin.
Unfortunately, these help files are not available in LDAP plugin
versions prior to 1.11.
(cherry picked from commit 824662a8)

return an empty list when called with maxLines = 0
added unit test for getLog(0) returning an empty list

(cherry picked from commit 75f58103)

[JENKINS-26781] Backport to 1.609

Using @Restricted(NoExternalUse.class) rather than @since for backported API additions (as opposed to b62a07c0).

Given the minefield that is databinding, that seems prudent.
(cherry picked from commit 8e0cbbc9)

Starting in 4f24a027 (1.587-SNAPSHOT, before #1443 or stapler #39), nestedDescribableOverridingId passes.
nestedDescribableSharingClass fails given {stapler-class: D3, kind: d3a}.
(Stapler has no way of interpreting kind since it knows nothing of Descriptor, only implementation class names.)
In master (3080573a), both fail in the way reported (only kind is passed in).
After adding stapler-class back, nestedDescribableOverridingId passes again.
(cherry picked from commit 1f41bec8)

(cherry picked from commit ef2b6580)

(cherry picked from commit 972db2a5)

newInstancesFromHeteroList should recover gracefully from the case that both kind and $class are missing.
(cherry picked from commit 17a88352)

(cherry picked from commit 343382b9)

(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)