WIP refactor(controller): move provider construction to provider/factory package

[ivankatliarchuk]

What does it do ?

• Introduces provider/factory package with SelectProvider(ctx, cfg, domainFilter) — a plain switch over cfg.Provider that constructs and optionally cache-wraps the provider based on cfg.ProviderCacheTime
• The controller calls providerfactory.SelectProvider directly; it no longer knows about individual provider packages, provider.NewCachedProvider, or provider construction logic

Motivation

The controller's buildProvider mixing orchestration concerns with provider-specific construction details (provider construction belongs in the provider tree, not the controller). The existing TODOs in the code already called for moving this logic to the provider package

(// TODO: example provider.SelectProvider(cfg, ...)).

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[k8s-ci-robot]

[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 raffo 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

[coveralls]

Pull Request Test Coverage Report for Build 23044379392

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 27 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.5%) to 80.14%

---

Files with Coverage Reduction	New Missed Lines	%
execute.go	27	79.45%

Totals
Change from base Build 23013548972:	0.5%
Covered Lines:	16686
Relevant Lines:	20821

---

💛 - Coveralls

[mloiseleur]

@ivankatliarchuk 🤔 I'm not sure whether I see any real benefits here. It's slightly better, yes.
There is still this massive switch and this import of every single provider, which is clearly an anti-pattern.

Wdyt about implementing a registry pattern in this factory?

Something like:

var providers = make(map[string]BuilderFunc)

func Register(name string, builder BuilderFunc) {
    providers[name] = builder
}

Each provider package can then call factory.Register("aws", NewXXXProvider) inside its init() function. This adheres to the Open/Closed Principle—the factory package never has to be modified when new providers are added.

[ivankatliarchuk]

Well I do agree. There is a PR #6133 that does exactly that, not a registry but with service‑locator style factory. My view is, we first move it away - then find a pattern. I could do it here, not a problem.

At the moment, because this provider builder is in controller, we could not reuse provider builder #6158 and test it end-2-end.

Your call.

[ivankatliarchuk]

var providers = make(map[string]BuilderFunc)

^ This is I'm not sure. Basically it will allow to reassing at runtime providers.

[ivankatliarchuk]

/retitle WIP refactor(controller): move provider construction to provider/factory package

[ivankatliarchuk]

no longer required