resolver: retry oauth token fetch on transient network errors

[wussh]

Summary

Blob/manifest fetches already retry transient network errors (ECONNRESET, EOF, 5xx, etc.) via retryhandler, but the OAuth token exchange during registry auth did not. A single flaky connection to the auth endpoint (e.g. auth.docker.io) fails the whole build even though a retry would succeed.

This extracts the retry/backoff loop in util/resolver/retryhandler into a generic WithRetry helper (used internally by the existing New handler, no behavior change there) and applies it to the token fetch requests in util/resolver/authorizer.go (GET, OAuth POST fallback, and anonymous token fetch).

Fixes #6981

Test plan

• go build ./util/resolver/...
• go vet ./util/resolver/...
• go test ./util/resolver/... (all existing tests pass, including TestBearerAuthFallsBackToAnonymousTokenWithoutSession which exercises the changed code path)
• gofmt -s clean on changed files

[tonistiigi]

• This doesn't seem to handle the client side authorizer "session/auth/authprovider/authprovider.go:132" what should be the default path.
• On the pull util/pull/pull.go:153, push util/push/push.go:109 and config paths, retryhandler.New already wraps the handler, creating nested retry behavior atm iiuc.

Not needed in this PR but should be in future follow-ups:

• Looks like cancellation is not quite efficient. If backoff is in sleep context cancellation can't cancel directly but needs to wait for sleep to finish.
• If 429 returns a low retry time (eg. under 10 sec) then we should just wait that time, otherwise error.

[wussh]

@tonistiigi Good catches, both confirmed:

1. authprovider.go:132 (FetchGrantAccess, the client-side default path) calls authutil.FetchTokenWithOAuth/FetchToken directly — this PR doesn't touch that file, so it's still unretried. Left out because I scoped this to the resolver-side authorizer; happy to add the same retryhandler.WithRetry wrap there too.

2. Confirmed nested retry on pull/push/config paths: retryhandler.New already wraps the whole fetch/push HandlerFunc there, and that handler goes through the resolver → authFetcher.fetchToken, which this PR now also wraps in WithRetry. So a persistent transient failure on token fetch backs off up to MaxRetryBackoff once inside the token retry, fails, bubbles up, and the outer handler retry starts the whole thing over — multiplying worst-case retry time instead of just adding one layer of protection.

Before I push a fix, which direction do you prefer for #2?

• (a) give the token-fetch retry its own smaller/capped backoff so nesting is bounded, or
• (b) skip the inner retry for callers that are already wrapped by an outer retryhandler.New (resolver would need a way to know that), or
• (c) something else you have in mind

And for #1, want it as a follow-up in this PR or a separate one?