Raise default permissions of JUnit5JenkinsRule

[strangelookingnerd]

Fixes #901

This PR raises the default permissions of JUnit5JenkinsRule to align with their JUnit4 counterparts.
It is important to notice that this change is breaking and will cause some JUnit5 based plugin tests to fail in case they rely on the fact that the default user / permission is Unauthenticated.

The alternative would be to leave the permissions as they are but make users aware of the differences in JUnit4 and JUnit5.

Migration

JUnit5 based tests may fail due to this change (as they expect to run in an Unauthenticated context) - like for example:

@Test
void testUnauthenticated(JenkinsRule r) throws Exception {
    DummySecurityRealm realm = r.createDummySecurityRealm();
    r.jenkins.setSecurityRealm(realm);

    MockAuthorizationStrategy strategy = new MockAuthorizationStrategy();
    r.jenkins.setAuthorizationStrategy(strategy);

    assertThrows(AccessDeniedException.class, () -> somethingUnauthenticatedUsersCanNotDo());
}

To restore the previous behavior tests need to explicitly impersonate an ANONYMOUS user like so:

@Test
void testUnauthenticated(JenkinsRule r) throws Exception {
    DummySecurityRealm realm = r.createDummySecurityRealm();
    r.jenkins.setSecurityRealm(realm);

    MockAuthorizationStrategy strategy = new MockAuthorizationStrategy();
    r.jenkins.setAuthorizationStrategy(strategy);

    try (ACLContext ignored = ACL.as2(Jenkins.ANONYMOUS2)) {
        assertThrows(AccessDeniedException.class, () -> somethingUnauthenticatedUsersCanNotDo());
    }
}

Testing done

Added org.jvnet.hudson.test.JenkinsRulePermissionTest to validate the behavior.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[timja]

Seems sensible, possible to evaluate impact? I guess this could be backported to the default version in PCT or BOM? Or are the numbers so low you could do a quick test?

[strangelookingnerd]

While many builds in jenkinsci/bom#4324 failed for reasons I can not really explain, there was only a single plugin that had test failures that are related to this change: https://ci.jenkins.io/job/Tools/job/bom/job/PR-4324/4/pipeline-console/?selected-node=9033

Since I'm the maintainer of that plugin this is not really a suprise to me 😄
I guess the number of plugins that have already migrated to JUnit5 and relied on the current behavior of permissions is diminishing. With that being said, the impact of this change will likely not be too noticable.

[timja]

I can not really explain

I think to get them to pass you would need to backport this PR to the pre ee9 branch: #906

I don't think JUnit 5 has been adopted very far so lets go for it, we can revert back if required.

[basil]

@strangelookingnerd In jenkinsci/bom#4689 I am seeing PCT-only failures of jenkins.plugins.foldericon.PermissionTest which can be reproduced locally. I only see the failures when custom-folder-icon is compiled with its release version of JTH and when the tests are executed with this PR. If the tests are both compiled and executed with the JTH version from this PR, everything passes. Not sure why, but in the meantime can we get a new release of custom-folder-icon to work around this?

[strangelookingnerd]

@basil Released the plugin as 2.19