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

So far none of them are real regressions but just that I needed to update tets

Now that User.impersonate() actually checks if the user is valid, User.get("user").impersonate() is expected to fail.
Use a DummySecurityRealm to make this user a valid user.

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.

Expose the computer runs and timestamp to api.

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.

This reverts commit 816f9d02.