[27.x backport] vendor.mod: put github.com/pkg/browser in the right group

[thaJeztah]

• backport vendor.mod: put github.com/pkg/browser in the right group #5407
• relates to vendor: github.com/pkg/browser v0.0.0-20240102092130-5ac0b6a4141c moby/buildkit#5304 (comment)

commit fcfdd7b (#5344) introduced github.com/pkg/browser as a direct dependency, but it ended up in the group for indirect dependencies.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.77%. Comparing base (d0c1a80) to head (869df10).
Report is 3 commits behind head on 27.x.

Additional details and impacted files

@@ Coverage Diff @@## 27.x #5408 +/- ##
=======================================
Coverage 59.77% 59.77% =======================================
Files 345 345 Lines 23405 23405 =======================================
Hits 13990 13990 Misses 8445 8445 Partials 970 970 

[thaJeztah]

Flaky test?

=== Failed
=== FAIL: e2e/registry TestOauthLogin (1.00s)
login_test.go:28: terminating PID 10523
login_test.go:33: assertion failed: expression is false: strings.Contains(string(output), "USING WEB-BASED LOGIN"): Failed to start web-based login - falling back to command line login...
Log in with your Docker ID or email address to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com/ to create one.
You can log in with your password or a Personal Access Token (PAT). Using a limited-scope PAT grants better security and is required for organizations using SSO. Learn more at https://docs.docker.com/go/access-tokens/
Username: 

[laurazard]

Flaky due to it failing to reach login.docker.com 😅

Failed to start web-based login - falling back to command line login...

I have a branch somewhere with a refactor/more e2e tests here, so I'll make sure this is more resilient. It's not testing the full login flow, just that the oauth login is triggered by a docker login, so if it fallbacks to regular login that's fine.

[thaJeztah]

I just noticed that we're swallowing the error there, which ... probably is fine, but wondering if we need some what to present it 🤔 (although not sure if we want a log.Debug because they're so ugly on the commandline.. maybe?

cli/cli/command/registry/login.go

Lines 171 to 177 in f75abad

	response, err:=loginWithDeviceCodeFlow(ctx, dockerCli)
	// if the error represents a failure to initiate the device-code flow,
	// then we fallback to regular cli credentials login
	if!errors.Is(err, manager.ErrDeviceLoginStartFail) {
	returnresponse, err
	}
	fmt.Fprint(dockerCli.Err(), "Failed to start web-based login - falling back to command line login...\n\n")

I wish the CLI had a location to log to (without that meaning "print and show the user")

[laurazard]

Yeah, we could do something like a log.Debug.

[thaJeztah]

It's a tricky one, due to the nature of the cli being short-lived; we'll be potentially opening a can of worms to handle concurrency, log-rotation, and multiple instances of the cli probably needing something to associate logs with each invocation.

Well, or have a new file created at all times, but we'd still need something to clean it up. Sending to a logging service would be ideal, but not available in all cases.