Send a User-Agent header on registry requests

[adityasingh2400]

Registry requests built by RegistryClient go out without a User-Agent header. The central request() method constructs an HTTPClientRequest and only ever sets Authorization plus whatever caller headers are passed, and AsyncHTTPClient does not add a default User-Agent of its own. As a result every registry operation (manifest resolves, blob fetches, token exchanges, and pushes) is anonymous on the wire, which is what the issue reporter saw when proxying the traffic.

HTTP/1.1 only recommends User-Agent rather than requiring it, but in practice some registries and forward proxies reject, rate-limit, or otherwise mishandle requests that omit it, and operators rely on it for attribution and debugging.

The client already carries a clientID (containerization-registry-client by default), but it was only used as the OAuth client_id form field when fetching tokens, never as an HTTP header. This sets the User-Agent from clientID at the single point where requests are constructed, so it applies uniformly to every registry call including retries and token fetches. A caller that supplies its own User-Agent in the per-request headers still takes precedence, and no duplicate header is emitted.

Added unit tests in ContainerizationOCITests covering the default User-Agent, propagation of a custom clientID, caller override, and coexistence with other headers. With the header omitted the new tests fail (the header reads as empty); with the fix they pass. Verified locally with swift test --filter RegistryRequestHeaderTests -Xswiftc -warnings-as-errors.

Reported in apple/container#1583 (the registry client lives in this repository).

[jglogan]

@adityasingh2400 Can you set push this with signed commits? We require that for merging.

Also, please rebase to the latest main to pick up a GH workflow change that fixes a test failure unrelated to your work. Thank you!

See also: https://github.com/apple/containerization/blob/main/CONTRIBUTING.md#pull-requests

[jglogan]

@adityasingh2400 Your commit is signed but unverified. The email that you use for your signing key needs to match an email that you've registered in your Github profile.

[jglogan]

@adityasingh2400 Also, please run make fmt on your change and push that commit. Once that's in place and your commit signatures appear as verified, we can build and merge your change. Thank you!

[adityasingh2400]

Thanks for the pointers, all three are done.

The signature problem was a repo-local user.signingkey override pointing at an old RSA key that was never registered on my GitHub account. I removed the override so the commit is signed with my registered SSH key, and the commit now shows as verified.

I also rebased onto the latest main to pick up the workflow fix, and re-ran make fmt (both swift format and the strict lint pass come back clean with no changes to my files, so there was nothing new to commit from it).

Ready for another CI run whenever you are.