Adjust http client to support rate limits

[mcncl]

Description

Changed the way that the CLI implements rate limits and the back off. We've removed the dependency on roko, which shouldn't be required with the availability of the RateLimit- headers that we can get from client calls.

Moves the logic in to a reusable HTTP transport so commands/clients can share it.

Changes

• Added RateLimitTransport in internal/http/ratelimit.go:
  • Retries on HTTP 429 up to MaxRetries
  • Uses RateLimit-Reset for backoff, with MaxRetryDelay cap
• Removed retry/backoff code from internal/http/client.go:
  • Deleted WithMaxRetries, WithMaxRetryDelay, WithOnRetry
  • Removed RetryAfter/retry loop from Client.Do
• Updated call sites to use transport-based retry:
• Extended pkg/cmd/factory/factory.go with WithTransport(http.RoundTripper) and composed it with debug transport.

Caveats

• Removed github.com/buildkite/roko from go.mod/go.sum.

Testing

• Tests have run locally (with go test ./...)
• Code is formatted (with go fmt ./...)

Disclosures / Credits

I used AI assistance (OpenCode / GPT-5.3 Codex) to review the diff, it highlighted a regression in some logic I'd written where if RateLimit-Reset was equal to 0 on check it would wait 10s.

[matthewborden]

Does this overwrite the retry behaviour for 429s in https://github.com/buildkite/go-buildkite/blob/main/buildkite.go#L383-L403? Could there be two backoff loops on top of each other for 429s if it doesn't?

[mcncl]

@matthewborden it does; go-buildkite uses a generic exponential backoff which will act as a fallback if our checks fail for some reason (missing headers or something)

We're using the RateLimit-Reset, which will mean we have an exact time for retrying, rather than the exponential value that go-buildkite might use

[matthewborden]

Let's address this in a followup PR, I'd prefer to have one backoff loop managing rate limit retries.