The OldDataMonitor should be using ACL.system not the ACL of the calling
thread - this also avoids the deadlock when an authorization strategy is
being saved (locking the auth strategy) which will call into the ODM at
the same point the ODM is being called an a Run has been saved (which will
cause a lookup of the job which will do a permissions check).

(cherry picked from commit 8a077a80)

- 252e1296 doesn't work for all cases as there are code paths
  where a pending launch can be removed from the pending list and not have spent() called.
- There was no reason for iterating the list twice anyway, as all of this takes place with the locks held
- My notifying each one as we process, if there is an Error, we will not leave any stranded. The next run
  through, if there is one, will cover those instances.

(cherry picked from commit 4f0ca16b)

- They have been removed from the pendingLaunches, so once we leave this method we have no reference to them
- Arguably the call to spent should take place when removing from the pendingLaunches, but that would change
  the method contract

(cherry picked from commit 252e1296)

Pick up the remoting 2.52 release
(cherry picked from commit aac20468)

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

(cherry picked from commit df831325)

(cherry picked from commit fabec0ee)

Amends eec43983.

(cherry picked from commit 1c1d5a95)

- I was forgetting the call to `rebuildDependencyGraph()` which was why the test didn't work for me

(cherry picked from commit c44c0884)

- One could argue that without this change the system is functioning correctly and that previous behaviour
  was a bug. On the other hand, people have come to rely on the previous behaviour.
- The issue really centeres around state changes in the blocked tasks. Since blocking on upstream/downstream
  relies on checking the building projects and the queued (excluding blocked) tasks we need any change in
  the blocked task list to be visible immediately (i.e. update the snapshot)
- I was able to reliably reproduce this behaviour with a convoluted set of manually configured projects
  but turning this into a test case has not proved quite as easy. Manual testing confirms that the issue is
  fixed for my manual test case
- I have also added a sorting of the blocked list when probing for tasks to unblock. This should prioritise
  tasks as intended by the QueueSorter

(cherry picked from commit de877367)

(cherry picked from commit 20bd4e30)

(cherry picked from commit 40e75129)

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)

- Rather fun one here. The Lock code relies on assuming that Thread.interrupted() is clear on entry
- If it then sees Thread.interrupted() set, it will interrupt the current thread in order to set the
  flag again.
- Executor is a thread that does funky things with an overridden interrupt method
- Executor.abortResult() is used to track a build be interrupted or aborted in some other way
- As a result the abortResult can cause a deadlockif there is a genuine interruption
- This fix clears the interrupt flag in abortResult() and uses the write lock in order to ensure:
    - The same lock as used in interrupt() is helf
    - The interrupt flag is clear
- Clearing the interrupt flag should be safe as the only time it is called is immediately after
  an interruption and the resulting exception is caught and rethrown/logged anyway

(cherry picked from commit ddb0a472)

(cherry picked from commit ae20c037)

(cherry picked from commit ce862f0b)

(cherry picked from commit 7db618e6)

- Typo
- Print error combined
- Set result only when phase like in other code parts.
- Test for expected error message in log

(cherry picked from commit 161a0092)

- Print publisher display name instead of class, so user can understand what publisher in UI was used and failed.
- Setter for artifact archiver shows how it handle status
- Minor typos
- Added test for stacktraces in build log

(cherry picked from commit 92734a83)

(cherry picked from commit 625a22e6)

(cherry picked from commit c6d4204a)

(cherry picked from commit c569036f)

Simple `<l:task post="true" href="someurl"/>` triggers post request as expected
but then proceeds to href as normal link to. If the URL accepts GET then request
is sent twice it if does not after POSTing on background user get
'POST is required' error.

(cherry picked from commit baa19249)

Squashed commits:
[73308b5] [FIXED JENKINS-27549] job loading can be broken by a NPE in a build trigger

(cherry picked from commit 4c0d3ac6)

(cherry picked from commit 17116a21)

[JENKINS-28419] - Direct unit tests for JenkinsLocationConfiguration::adminAddress setter and getter

(cherry picked from commit dab392f8)

[JENKINS-28446] - Introduce new API method in Queue to optimize the performance of UnlabeledLoadStatistics

(cherry picked from commit 7697bdb4)

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)