Refactor passing / handling of user-agent

Description

• relates to https://github.com/moby/moby/pull/45185

While working on https://github.com/moby/moby/pull/45185, I found there to be a couple of issues related to how we pass the user-agent.

For context; when making requests to registries, we combine the client's user-agent (e.g. user-agent of the docker CLI) with the user-agent of the daemon itself (version, build, kernel-version).

There's a couple of issues;

• constructing the user-agent of the daemon involves getting kernel-version, which is not "cheap". Assuming the kernel version doesn't change while the daemon is running, we should do this once (could be a sync.Once)
• getting the above information also brings additional dependencies, so we need to be careful where we include that code (to prevent consumers of the API (client) from getting those additional dependencies
• there is no consistent approach "where" to set the user-agent; some endpoints set the information in the API, other parts set it implicitly "deep" in library code
• there is no consistent approach on how to pass the user-agent; some code uses a separate userAgent argument, whereas others pass it as part of the (meta)Headers (these headers can be custom headers set through X-Meta-xxx).
• Some code pass both User-Agent and metaHeaders to the registry, whereas other parts of the code discard metaHeaders ⚠️ ❓ Is there a reason to discard metaHeaders ?; see
  • https://github.com/moby/moby/blob/b19dbee3f76504356fb7d63f36d8e44438b23cdc/registry/search.go#L119
  • https://github.com/moby/moby/blob/b19dbee3f76504356fb7d63f36d8e44438b23cdc/registry/endpoint_v1.go#L124

We should consider;

• Improve performance (use a sync.Once?)
• Alternatively; set the information when constructing the router and/or backend, and store it on the backend itself.
• Move this code out of library code; don't set it implicitly, but pass it as part of the headers we pass as arguments
• Having a consistent approach (should we append the User-Agent to all requests? if it's a lightweight operation, then perhaps that's an option; even if we're not gonna be using it)
• Find out why metaHeaders is discarded in some cases (was it (e.g.) to prevent authentication headers from being taken from X-Meta- headers? Other reason?) See https://github.com/moby/moby/commit/19d48f0b8ba59eea9f2cac4ad1c7977712a6b7ac / https://github.com/moby/moby/pull/24568 for an example where metaHeaders is discarded

Start by reviewing registry/search.go around line 119 and registry/endpoint_v1.go around line 124, then trace how the daemon and client user-agents and metaHeaders reach registry requests. Compare the related PR and commit references to understand why metaHeaders are discarded; done requires an agreed, consistent approach that addresses the listed performance, dependency, and header-handling concerns.