skip 'gh auth status' in CI runs

[jameslamb]

We've recently observed some issues across RAPIDS CI that look like we're hitting the GitHub REST API's rate limits: https://github.com/rapidsai/build-infra/issues/241

This proposes some changes to hopefully reduce the incidence of that:

• not running gh auth status in CI (see notes below)
• increasing the wait between retries of failed gh commands from 30 to 120 seconds

Also proposes one minor refactoring:

• invoking, instead of source-ing rapids-prompt-local-github-auth
  • not really related to this issue, but it'd reduce the risk of conflicts in variable names

Notes for Reviewers

How does avoiding gh auth status calls help?

I found in local testing that those do make network requests!

Try this:

# authenticate
gh auth login

# check status
gh auth status

You should see that succeed. Turn off your WiFi and do that again.

gh auth status

You'll see it fail!

I think the request it's making is to get the scopes for the current token:

https://github.com/cli/cli/blob/1e6a2b1affb7d6a7850f4bc0e7a43cf14b80caf5/pkg/cmd/auth/status/status.go#L214

https://github.com/cli/cli/blob/1e6a2b1affb7d6a7850f4bc0e7a43cf14b80caf5/pkg/cmd/auth/status/status.go#L305

https://github.com/cli/cli/blob/1e6a2b1affb7d6a7850f4bc0e7a43cf14b80caf5/pkg/cmd/auth/shared/oauth_scopes.go#L38

I can't quite tell what endpoint it's hitting so not sure whether that's actually counting towards our rate limit. But avoiding those requests in CI would be valuable even if they don't count against our rate limit... every network request is an opportunity for a build-breaking transient failure 😬

If these do count against our rate limits, then this PR would cut the number of requests to the GItHub API per run roughly in half, because rapids-prompt-local-github-auth is called on every code path from gha-tools invoking the gh CLI (as of #172).

How I tested this

Tested on a cugraph PR.

See rapidsai/cugraph#5091 (comment)