(cherry picked from commit aaa71d4f)

This reverts commit df4bb2de.

This reverts commit 3c471f1f.

(cherry picked from commit e9471744)

(cherry picked from commit 67cce202)

(cherry picked from commit 9a57858a)

(cherry picked from commit 2c5deeb6)

(cherry picked from commit d72d7b83)

[FIXED JENKINS-29989] Update RunIdMigrator to properly handle matrix and Maven jobs
(cherry picked from commit 3d7878ff)

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)

[JENKINS-28440] Reject configurations with errors in critical fields via REST / CLI

[JENKINS-29936] when removing an item use ACL.SYSTEM.

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

Fixed typos in pt_BR and pt_PT translations

[FIXED JENKINS-2327] Do not display 'No changes' if changelog calcula…

[JENKINS-28690] Aha! So I believe this will fully resolve any of these kinds of deadlocks

[FIXES PR#1777] Make accessing pendingLaunches lock free

Update link to Groovy

Codehaus terminated all services - now Groovy's new home is groovy-lang.org.

- My objection to #1777 is that it is introducing more locking. The ultimate aim is to make
  node provisioning and queue maintenance completely lock free. Thus adding more locks than
  is strictly required is a bad plan.
- We cannot completely remove provisioningLock at this time as it is used to ensure that
  only one provisioning activity can take place for a given label at a time.
- This change ensures that the provisioningLock is only used by the NodeProvisioner for
  its internal thread guarantees and is thus no-longer used accidentally by any
  external threads

- Without this, then it becomes a question of find catch and release for each potential code path that
  might end up restoring the interrupt flag on the current thread.
- Since standard Lock support is kind enough to restore the interrupt flag on the current thread
  when blocked waiting for the lock, that would be a hiding to nothing
- I welcome others to review my logic detailed in the code comment
- I am leaving the code comment as this is IMHO too important to assume that somebody will
  check the git commit history

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

Avoid "EmptyStackException: null" in Items#getCanonicalName

Conflicts:
	core/src/main/resources/hudson/model/Messages.properties
	core/src/main/resources/hudson/model/Messages_de.properties
	core/src/main/resources/hudson/model/Messages_it.properties
	core/src/main/resources/hudson/model/Messages_ja.properties
	core/src/main/resources/hudson/model/Messages_zh_TW.properties
	core/src/main/resources/jenkins/model/Messages.properties
	core/src/main/resources/jenkins/model/Messages_da.properties
	core/src/main/resources/jenkins/model/Messages_de.properties
	core/src/main/resources/jenkins/model/Messages_es.properties
	core/src/main/resources/jenkins/model/Messages_fr.properties
	core/src/main/resources/jenkins/model/Messages_it.properties
	core/src/main/resources/jenkins/model/Messages_ja.properties
	core/src/main/resources/jenkins/model/Messages_nl.properties
	core/src/main/resources/jenkins/model/Messages_pt_BR.properties
	core/src/main/resources/jenkins/model/Messages_ru.properties
	core/src/main/resources/jenkins/model/Messages_tr.properties
	core/src/main/resources/jenkins/model/Messages_zh_CN.properties
	core/src/main/resources/jenkins/model/Messages_zh_TW.properties

Make it easier to determine Computer is Unix or Windows

[JENKINS-26147] New home for BUILD_NOW_TEXT