Null check the 'properties' element of the json message before attempting to 'rebuild' the 'DescribableList'

Plugins like github-oauth-plugin implementing SecurityRealm need to call
these methods in security lifecycle events.

[JENKINS-21631] - Don't fail with NPE if the PeepholePermalink cache contains the non-numeric value.

Actually, the change just prevents symptoms. There should be an error somewhere else.
Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>

Integrated the fix made in winp 1.20.

Link to 'Building Jenkins' page from text file

MockFolderTest.moving pointed out a refinement to 1197e0ce: list folders, if included, before their contents.

Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>

Move entries older than last year to changelog-old

Cf.: https://github.com/jenkinsci/metrics-plugin/commit/b7a2f58c977c8d1053d702e36dcc36bb1348e1aa

Improved robustness of RunParameterValue so it does not break the REST API when there is invalid data.
Observed in 1.554.1:
java.lang.ArrayIndexOutOfBoundsException: 1
        at hudson.model.RunParameterValue.getNumber(RunParameterValue.java:63)

Fix translation error

[JENKINS-23365] Follow-up API fixes: introduce SCM.getKey(), and add an SCMRevisionState baseline argument to checkout.
Necessary in order to produce correct changelogs by SCM plugins which actually use SCMRevisionState correctly (unlike git-plugin!).
(cherry picked from commit df9dc4c8)

(cherry picked from commit abf33593)

[FIXED JENKINS-20327] When saving a list view, submit POST data with size proportional to the # of jobs selected for inclusion, not the number of options.
This can be done easily by setting json="true"; otherwise the default is to pass =false for each unselected job.
Ironically, even with this fix we are sending 2× what is needed,
since currently ListView.submit does not even check the json parameter for job names:
it only pays attention to top-level request parameters that the browser defines for selected checkboxes.
Ideally we could ask buildFormTree to ignore a given form element entirely, so as to avoid the wasted data.

[JENKINS-19310] Unreproducible failure of DirectlyModifiableViewTest.failWebMethodForIllegalRequest, probably from a StackOverflowError.
	at …
	at hudson.model.View.toString(View.java:514)
	at java.text.MessageFormat.subformat(MessageFormat.java:1246)
	at java.text.MessageFormat.format(MessageFormat.java:836)
	at java.text.Format.format(Format.java:140)
	at java.text.MessageFormat.format(MessageFormat.java:812)
	at java.util.logging.Formatter.formatMessage(Formatter.java:130)
	at java.util.logging.SimpleFormatter.format(SimpleFormatter.java:63)
	at java.util.logging.StreamHandler.publish(StreamHandler.java:179)
	at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
	at java.util.logging.Logger.log(Logger.java:481)
	at java.util.logging.Logger.doLog(Logger.java:503)
	at java.util.logging.Logger.log(Logger.java:567)
	at hudson.model.AbstractItem.getUrl(AbstractItem.java:423)
	at hudson.model.View.getViewUrl(View.java:510)
	at hudson.model.View.toString(View.java:514)
	at …

The basic fix is to use ${rootURL} plus full model object URLs rather than relying on ${jobBaseUrl}.
This is made trickier by the fact that the model object URLs are computed inside ProgressiveRendering.compute,
and therefore will not be correct when nondefault views are in the crumb trail unless the original request information is present.
So modifying ProgressiveRendering to preserve a copy of the original request for use during computation.
(This could probably be used to simplify parts of AsynchPeople as well.)
Also improving AbstractItem.getUrl to properly construct a URL including views even when the current page is not inside the item;
it should suffice for some ancestor of the current item (or a view thereof) to be in the ancestor list of this page.