fix(aws): incorrect behavior for non-aliasable record types

[u-kai]

What does it do?

This PR refactors the alias-handling logic inside adjustEndpointAndNewAaaaIfNeeded and fixes incorrect behavior for record types that do not support AWS Alias records (e.g., MX, TXT, SRV, etc.).

The work was performed in several steps to ensure correctness:

1. Extracted the alias-handling logic
   to make the behavior easier to reason about and test.

2. Added temporary compatibility tests
   to verify that the refactored logic produced identical results to the previous implementation.

3. After confirming functional parity, applied fixes
   so that non-aliasable record types no longer receive alias-related modifications.

4. Added comprehensive tests
   covering A / AAAA / CNAME alias behavior and non-aliasable record types.

5. Removed the temporary compatibility tests and old logic
   once correctness and stability were fully validated.

As a result, the final codebase contains the refactored logic and the new test suite, while the transitional scaffolding used to guarantee correctness has been removed.

Motivation

This work originated from the discussion here:
#5997 (comment)

During the investigation, I found that:

• The existing function mixes multiple responsibilities, making correctness difficult to reason about.
• Alias-specific logic was being unintentionally applied to non-aliasable record types.
• Adding tests for this logic was difficult due to the tight coupling inside the function.

To address this safely, I followed a staged approach:

• First refactored the logic into smaller units.
• Added a temporary test suite to confirm behavioral parity.
• Introduced the fixes without risking regressions.
• Replaced the temporary tests with a final, comprehensive set.

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

[k8s-ci-robot]

Hi @u-kai. Thanks for your PR.

I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[ivankatliarchuk]

Refactoring and bug fix in single PR. Too risky. As well as for bug, it should be manifests provided to reproduce

[u-kai]

@ivankatliarchuk
Sorry about that — I’ll be more careful next time.

To make the existing issue easier to fix, I’ve opened a separate PR with the refactoring work.
Once that PR is merged, I will rebase this PR and continue the bug fix on top of it.

It would be great if you could review the refactoring PR first. Thanks!