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

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.