Null out ProxyConfiguration.userName on save

[jglick]

Analysis of a bug report for CloudBees CI showed that when a proxy was configured with a username & password, uses of newHttpClientBuilder would (silently!) fail to pass an Authorization header to the real server, but only on Java 17 or newer. (As of openjdk/jdk@028f2e1 I think; the same code works on Java 11.) This issue is described in JDK-8306745 complete with a unit test, but alas that was closed. The test there looks similar to the Jenkins authenticator, including the logic

jenkins/core/src/main/java/hudson/ProxyConfiguration.java

Line 162 in f7fea8d

if (getRequestorType() == RequestorType.PROXY && userName != null) {

which correctly reserves the authentication for the proxy server. So far as I can tell there is no practical way to make newHttpClientBuilder behave correctly on Java 17 when an authenticated proxy is configured: the bug evaluation says you should

[not] use any authenticator, and explicitly handle 401/407 in the calling code

which is only an option if the complete usage including request is redesigned to manually check for a 407 and retry with a Proxy-Authorization header, but that logic cannot be encapsulated in a HttpClient.Builder return value unless Jenkins implemented its own Builder and a special delegating implementation of HttpClient.

While looking at that, I saw that the reproducer claimed the bug occurred even when a username was not set, which seems to be because the GUI configuration of the proxy after #3935 saved "" rather than null when the username text field was left blank. This at least is easy to fix, limiting the scope of the problem.

Testing done

Without setUserName change, test fails

java.lang.AssertionError: expected null, but was:<>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotNull(Assert.java:756)
	at org.junit.Assert.assertNull(Assert.java:738)
	at org.junit.Assert.assertNull(Assert.java:748)
	at hudson.ProxyConfigurationManagerGUITest.lambda$configRoundtrip$1(ProxyConfigurationManagerGUITest.java:51)

Proposed changelog entries

• Proxy configuration saved via the GUI always configured an authenticator even if the username was blank.

Before the changes are marked as ready-for-merge:

Maintainer checklist

Edit tasklist title

Beta Give feedback Tasklist Maintainer checklist, more options

• Rename
• Copy markdown
• Delete tasklist

Delete tasklist

Delete tasklist block?

Are you sure? All relationships in this tasklist will be removed.

Cancel Delete

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.

   There are at least two (2) approvals for the pull request and no outstanding requests for change.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.

   Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
3. Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood.

   Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
4. Proper changelog labels are set so that the changelog can be generated automatically.

   Proper changelog labels are set so that the changelog can be generated automatically.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
5. If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](https://github.com/jenkinsci/jenkins/pull/4387)).

   If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)).

   If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove

Add item to Maintainer checklist

[NotMyFault]

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!