Extract AWS specifics from zone type filter

[mrueg]

What does it do ?

Fixes: #5983

Motivation

This will reduce dependencies in any external providers importing the provider package.

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 mloiseleur for approval. For more information see the Code Review Process.

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

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

[mrueg]

I moved this below, since it was only used by the aws provider.

[mrueg]

I wonder if the p.zoneTypeFilter.Match(zone) is even necessary here?

[mrueg]

Goal of this exercise is to get this out of the provider package.

[coveralls]

Pull Request Test Coverage Report for Build 20077740660

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 68 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.008%) to 78.687%

---

Files with Coverage Reduction	New Missed Lines	%
execute.go	24	64.92%
aws/aws.go	44	90.78%

Totals
Change from base Build 20069516202:	0.008%
Covered Lines:	16012
Relevant Lines:	20349

---

💛 - Coveralls

[ivankatliarchuk]

The work make sense to me.

I’m not sure if I agree with how this proposal is implemented. It would likely make more sense as an interface rather than a concrete injection into an AWS-specific method. That’s a sign of increased coupling and responsibility leak.

ZoneTypeFilter is now tightly bound to AWS semantics.

It will not generalise well for:

• Google Cloud DNS
• Azure Private DNS
• other providers if we going to add filters

The fallback/implicit behaviour becomes harder to reason about

if zone.Config == nil {
    // assume public zone unless config exists
    IsPublicZone = p.zoneTypeFilter.ZoneType == provider.ZoneTypePublic
}

This is domain-behaviour logic, but it's mixed into:

• provider implementation
• filter implementation
• zone loop

The boundary between filter logic and provider domain semantics is blurring.

This means, from one perspective:

• Harder to maintain
• Harder to introduce new filters
• Harder to test filter construction and logic in isolation

And potentially goes in the opposite direction of:

• Clean architecture
• Provider and filters abstraction
• Pluggable filter interfaces
• Testability across providers