🐛 controller: cap BareMetalHost reconcile backoff at 30 seconds

[MahnoorAsghar]

What this PR does / why we need it:
The default controller-runtime exponential rate limiter has a maximum delay of 1000 seconds (~16 minutes). During BMO startup there is a brief race between the reconcile loop becoming active and BMO's own validating-webhook Service endpoint being propagated: any BareMetalHost reconciliation that triggers a webhook call in that window gets a "no endpoints available" error. A burst of such errors is enough to drive the per-item exponential backoff to its ceiling, after which BMO silently waits up to 16 minutes before attempting the next reconcile even though the webhook has long since become reachable.

Replace the default rate limiter with one that is otherwise identical but caps the per-item exponential delay at 30 seconds. This bounds the recovery window to at most one retry interval after the endpoint is propagated, matching the behaviour of other Metal3 controllers.

Generated-by: Cursor, claude-4.6-sonnet-medium model

Checklist:

• Documentation has been updated, if necessary.
• Unit tests have been added, if necessary.
• E2E tests have been added, if necessary.
• Integration tests have been added, if necessary.

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign honza for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dtantsur]

Is #3162 solving the same problem? Do we need both?

[MahnoorAsghar]

@dtantsur They're both needed, AFAIU

[Copilot]

Pull request overview

This PR adjusts the BareMetalHost controller’s reconcile rate limiting to avoid long per-item exponential backoffs after transient webhook endpoint propagation failures during BMO startup.

Changes:

• Replace the default controller-runtime rate limiter with a custom one that caps per-item exponential backoff at 30s (instead of ~1000s).
• Add the required imports and promote golang.org/x/time to a direct dependency.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/controller/metal3.io/baremetalhost_controller.go	Introduces a custom typed workqueue rate limiter (exponential backoff capped at 30s + token bucket) via controller options.
go.mod	Adds golang.org/x/time as a direct requirement to support the token bucket limiter.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Sunnatillo]

Sorry, But I am not convinced this change is needed.
IMHO, the time between webhook ready and endoint available is not huge. Lets says 10s(probably way less). The exponential backoff never reaches 16 minutes that we are saying here.

[metal3-io-bot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.