perf(mr): fewer API calls when opening an MR in the browser

kangrequested to merge
gitlab-community/gitlab-org/cli:kang8-perf-mr-view-web-fewer-api-calls into main

What does this MR do and why?

glab mr view --web only needs one thing: the merge request's web URL. Today it makes up to three serial API requests before the browser opens.

For glab mr view --web (branch resolved from the current checkout):

  1. GET /projects/:id/merge_requests?source_branch=… — resolve the branch
  2. GET /projects/:id/merge_requests/:iid — with include_diverged_commits_count, render_html and include_rebase_in_progress
  3. GET /projects/:id/merge_requests/:iid/approval_state

Request 3 runs unconditionally, before the --web check, and its result is only ever consumed by the terminal output path (printTTYMRPreview). Request 2 is redundant when the merge request was resolved from a branch, because the list response in request 1 already carries web_url for every merge request (REST API docs, BasicMergeRequest.WebURL in client-go).

This MR moves the --web early return to the top of the command and resolves the URL with the fewest possible requests.

Invocation Before After
glab mr view --web (by branch) 3 requests 1
glab mr view 123 --web (by ID or URL) 2 requests 1

Terminal output is unchanged — the approval state fetch still happens on every path that renders it.

Prior art

GitHub's cli/cli solves the same problem the same way: gh issue view --web requests only the url field rather than the full entity (pkg/cmd/issue/view/view.go, lookupFields.Add("url")).

Implementation notes

The argument parsing in mrutils.MRFromArgsWithOpts — merge request URLs, !-prefixed and bare IDs, cross-host client switching, falling back to the current branch — is extracted into resolveMRTarget, which makes no API calls. MRFromArgsWithOpts keeps its exact previous behaviour on top of it, and the new MRWebURLFromArgs reuses it but stops as soon as a URL is known.

No new configuration keys, no new dependencies, no changes to generated docs.

How to set up and validate locally

# Three requests before this MR, one after:
GLAB_DEBUG_HTTP=1 glab mr view --web 2>&1 | grep -c '^REQUEST:'

# Terminal output is untouched:
glab mr view
glab mr view 123 --comments

TestMRViewWeb covers both paths and asserts the number of merge request fetches (0 for the branch path, 1 for the ID path) alongside the resolved URL.

MR acceptance checklist

  • Tests added for new functionality
  • make lint passes
  • No user-facing documentation changes required (no flag or help text changed)

Merge request reports