[FIXED JENKINS-19544] When OldDataMonitor is reported a Run, just remember the ID rather than holding a strong reference.

[JENKINS-19544] Whether or not we manage to save an object with old data, be sure to remove it from the list, and continue with other objects.
Otherwise a bug like JENKINS-20950 can prevent *anything* from being saved, and holds references to all the old data.

Integrated the new version of XStream that contains the fix.

Protect the common thread pool against poorly written tasks that do not restore original context classloader.

Reference: RM-2329 in CloudBees

list-jobs should print names, not display names, since people expect to be able to feed the results into other CLI commands.

See comments in ce7e6390; and note reverted 71f3acfc.

This reverts commit 71f3acfc.
Test regressions

Not sure why it didn't in ce7e6390.

The fix allows to explicitly disable automatic page refreshes in the @View extensions.
Resolves https://issues.jenkins-ci.org/browse/JENKINS-21190



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

The intent of this test is to make sure that a floating User object without any storage returns false from canDelete() method.
The earlier change made User.impersonate() to actually check if the user is a valid, so to make this test case work where it does
"user.impersonate" and "user2.impersonate2", I'm creating valid accounts for these two users.

Now what that means is that user2 is no longer a floating flyweight storage-less User, so it breaks the assumption of the
"User should not be able to delete because he is not saved." assertion.

To make this test case work, I'm introducing the 3rd user that is storage-less, and using it for the test.

These tests weren't using a SecurityRealm that recognizes these user names

There seems to be no way to export this over the REST API without incurring serious performance penalties.

Fix terminology used in BuildTrigger conditions

Added some missing German translations