[JENKINS-72016] Define a thread pool for ProxyConfiguration’s HttpClient

[jglick]

#7398 advertises a standardized HttpClient factory, and says

The returned instances of HttpClient […] are intended to be short-lived, not to be stored in memory in some sort of cache […].

When this advice is followed in some CloudBees CI plugins, obtaining a fresh HttpClient per request, under some circumstances where many requests are made the result is a gigantic number of threads with HttpClient in the name, eventually crashing the controller.

See JENKINS-72016.

Testing done

Ran the new test with

watch 'jstack $(jps -lm | fgrep booter | awk "{print \$1}")|egrep \^\"|wc -l'

Prior to patch: the test slows down and finally hangs without making it to 9000 requests. There are in the vicinity of 18000 threads in the JVM at this point. Sometimes the JVM crashes with OutOfMemoryError claiming it cannot create a new native thread. (This is pre-Loom!)

After patch: the test runs steadily to completion. The JVM thread count fluctuates around 4000 or so. A new HttpClientImpl.SelectorManager thread is created each time, but these seem to terminate themselves fairly soon rather than piling up indefinitely.

Proposed changelog entries

• Do not create a large number of threads when making numerous HTTP requests.

Proposed upgrade guideliness

N/A

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

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
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).
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).

[jglick]

Takes <1m on my laptop, so I am hoping this is reasonable to keep as is. If not, it could be @Ignored or deleted.

[Vlatombe]

Looks reasonable and fixes the performance issue when using a lot of throw-away HttpClients

[Vlatombe]

Looks reasonable and fixes the performance issue when using a lot of throw-away HttpClients

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[timja]

(removed ready for merge, the new test is failing on windows)