Fix JENKINS-51638 - allow lower case 'default' UserMergeStrategy

[MarkEWaite]

JENKINS-56138 - Handle lower case 'default' UserMergeStrategy value

Some users upgrading from prior git plugin versions to git plugin 3.9.x received error messages that their merge strategy value was not recognized. They had used 'default' as the value instead of 'DEFAULT' and the new code only accepted 'default'. This code now accepts all case variants of 'default'.

Checklist

• I have read the CONTRIBUTING doc
• I have referenced the Jira issue related to my changes in one or more commit messages
• I have added tests that verify my changes
• Unit tests pass locally with my changes
• I have added documentation as necessary
• No Javadoc warnings were introduced with my changes
• No findbugs warnings were introduced with my changes
• I have interactively tested my changes
• Any dependent changes have been merged and published in upstream modules (like git-client-plugin)

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Further comments

Relies on structs 1.18 for an API enhancement. Requires Jenkins 2.121.1 or newer. Backport of #699

[jglick]

Looks fine. I assume you will do a quick interactive sanity check that the bug as reported was reproducible in this branch before but not after this PR.

[jglick]

There are some test failures which do not seem to be in the base branch. They do not look obviously related to me—all involve an unexpected commit hash somewhere. Reproducible?

[MarkEWaite]

Those test failures are intermittent and are also on the base branch. They seem to have become intermittent as a result of either the upgrade to Jenkins 2.121 or to the latest parent pom. When I configure surefire retries they will typically pass within the 5 retries that are configured. I've seen them intermittent on Ubuntu 16, Debian 10, FreeBSD 12, and Windows. In each of those cases, the surefire retries were enough to achieve a success by the fifth retry.

I'm prone to annotate those tests with @Ignore on the base branch for now and investigate later why they became intermittent with the transition from Jenkins 1.642 to Jenkins 2.121. I suspect it is related to timing assumptions, but I don't really have time to do the detailed investigation of those failures right now.