Enable automatic proxy configuration from JVM system properties

[somiljain2006]

Fixes ~#16780

Enable automatic proxy configuration from JVM system properties during initial setup to prevent hangs in restricted network environments. Previously, Jenkins ignored standard flags such as -Dhttp.proxyHost and -Dhttps.proxyHost until a proxy.xml file was created, which could cause connection timeouts on first startup. This change provides a fallback to those system properties when no persisted proxy configuration is present.

Testing done

Ensured all tests still passed.

Proposed changelog entries

Jenkins now applies standard JVM proxy system properties during the initial startup when no proxy configuration is present.

Proposed changelog category

/label bug

Proposed upgrade guidelines

N/A

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

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• 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).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

Desired reviewers

@jenkinsci/core-pr-reviewers

[NotMyFault]

You have created plenty of PRs so far, and none match our acceptance criteria. Many have been closed due to fundamental issues that should have been caught before submission. This pattern suggests you're moving too quickly from issue to PR without fully understanding what your LLM submits there.

I recommend closing the existing ones and focusing on understanding, not output.

I appreciate your enthusiasm, but effective open source contribution requires patience, depth, and learning from maintainer feedback. Not submitting more and more LLM-generated PRs, given this effectively wastes maintainers time.

We're in somewhat of an uncanny valley in the industry right now, and there's quite an asymmetry in the cost of our time versus the cost of AI producing work for us to review. We likely will reject further submissions early, allowing us to focus on useful submissions.

[somiljain2006]

@NotMyFault
Thank you for the direct feedback. I understand the concern.

You’re right that I moved too quickly from issue to pr, and that some submissions did not meet the project’s expectations. I take responsibility for that and agree I should slow down and focus more on understanding the codebase before proposing changes.

For clarity, I do use AI as a supporting tool at times (for example, while debugging or understanding unfamiliar parts of the code), but the decisions and submissions are mine. However, I need to improve the depth and preparation of my submissions.

I will now focus on learning from existing code and issues. Please let me know if you would prefer that I close the current open pr's as part of that process.

I appreciate the time you and other maintainers have spent reviewing my work.

[NotMyFault]

Checks report that a plenty of coverage is missing.

[somiljain2006]

@NotMyFault, I have added the required test. Can you please review it?

[daniel-beck]

I'd like to see evidence that this PR solves a problem anyone has that is not their own network misconfiguration (and only causing a wait for timeouts) as hypothesized in #16780 (comment).

[somiljain2006]

@daniel-beck
I was not able to reliably demonstrate a clear timeout difference in my local environment, so I agree that the timeout behavior depends on network conditions.

However, I was able to consistently observe a configuration discrepancy:

On the current master, Jenkins does not initialize ProxyConfiguration from JVM system properties when proxy.xml is absent.

With this change, Jenkins explicitly initializes its internal proxy configuration from the provided JVM flags at startup.