upstream: fix: set MaxIdleConnsPerHost on internal HTTP transports (goharbor/harbor#23591)

[github-actions]

This cherry-pick had conflicts and was opened as a draft. Conflict markers may be present in the diff and must be resolved before marking ready for review.

Summary

Cherry-picks upstream Harbor commit c2c27ed2d from goharbor/harbor#23591.

Upstream Context

• Upstream PR: fix: set MaxIdleConnsPerHost on internal HTTP transports goharbor/harbor#23591
• Upstream commit: c2c27ed2d617eee7a53b6c130a73c06668f910c8
• Upstream title: fix: set MaxIdleConnsPerHost on internal HTTP transports
• Upstream author: @chlins
• Upstream merged by: @chlins
• Upstream approved by: @stonezdj, @wy65701436
• Upstream PR URL: fix: set MaxIdleConnsPerHost on internal HTTP transports goharbor/harbor#23591
• Upstream commit URL: goharbor/harbor@c2c27ed

Cherry-Pick Status

• Status: conflicted
• Base branch: main
• Workflow run: https://github.com/container-registry/harbor-next/actions/runs/30649285268

Upstream Description

Comprehensive Summary

Go's http.Transport defaults MaxIdleConnsPerHost to 2. Harbor's internal traffic is dominated by single-host hotspots (core → registry reverse proxy, registry API client, jobservice → core hooks, scanner adapter client), so under high concurrency almost every connection is closed after use. The resulting churn piles up client-side TIME_WAIT sockets and eventually exhausts ephemeral ports:

http: proxy error: dial tcp 172.18.0.4:5000: connect: cannot assign requested address

Changes:

• common/http/transport.go: newDefaultTransport() now sets MaxIdleConns=1000 / MaxIdleConnsPerHost=200, covering the registry client, core↔jobservice, webhook jobs and replication adapters.
• server/registry/proxy.go: the core → registry reverse proxy previously fell back to http.DefaultTransport when internal TLS is disabled; it now always gets a dedicated transport with MaxIdleConns(PerHost)=1024, as all /v2/ data-plane traffic targets a single host.
• jobservice/hook/hook_client.go / pkg/scan/rest/v1/client.go: per-host idle pool now matches MaxIdleConns (20/100), since each client only talks to one endpoint.

These knobs only enable connection reuse — idle connections beyond actual need are still reaped by IdleConnTimeout, and peak connection count remains driven by concurrency. No behavior change.

Issue being fixed

Observed on a docker-compose deployment under high-concurrency pulls; core floods proxy error: context canceled followed by cannot assign requested address on the core → registry hop.

Review Notes

• Generated by the upstream cherry-pick workflow.
• One upstream commit maps to one Harbor Next PR.
• If this PR is closed without merge, the workflow will not recreate it.

Upstream-Commit: c2c27ed2d617eee7a53b6c130a73c06668f910c8
Upstream-PR: goharbor/harbor#23591
Cherry-Pick-Status: conflicted