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

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-21190Signed-off-by: NOleg Nenashev <o.v.nenashev@gmail.com>

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

See javadoc for discussion why this possibly redundant use is desirable

I think the cleanest place to do this is as a filter of UserDetailsService.

The problem is that SecurityRealm defines loadUserByName method, which AbstractPasswordBasedSecurityRealm overrides

So ApiTokenFilter no longer needs to do that.

Jenkins now remembers the authorities (read group memberships) that the user had carried when he/she last time interactively logged in.
This information is exposed via User.impersonate(), which is used when using Jenkins SSH, Jenkins CLI, or access via API tokens.

Previously this was impossible for a subset of SecurityRealms that does not allow us to read group membership information without
successful login (such as Active Directory, OpenID, etc.)

For security reasons, if the backend determines that the user does not exist (as opposed to the backend who cannot tell if the user
exists or not), then the impersonation will fail.

I need to check AD plugin is reporting a failure correctly in this case, before marking as JENKINS-20064 fixed.

An unexpected failure in processing remember me cookie should be handled
gracefully. In particular, possibly problematic cookie should be
removed, or else the browser will keep bombarding the server with the
same cookie, and will never be able to get through.

It's much better to just drop the cookie.

(Left the upstream pseudo-trigger out of this, as it is pretty hackish and might not generalize well—requires Publisher’s to make any sense.)

* Use model-links with context menu
* Show the display name of the linked job
* If the build isn't available, but the job is, still link to the job

If the result needs to be SUCCESS, it needs to be called 'stable',
not 'successful' -- the latter is UNSTABLE or better.

References:
- PermalinkProjectAction (lastStableBuild for SUCCESS,
  lastSuccessfulBuild for UNSTABLE or better)
- Last Successful list view column (includes unstable builds),
  Last Stable column (doesn't)