AWS Route53 DNS migration doesn't update txtOwnerId if there is no change #6671

What happened:
I'm trying to migrate existing DNS records (using txt registry) to a new cluster and noticed a behaviour difference between AWS Route53 vs Azure DNS.

When migrating with --migrate-from-txt-owner flag, AWS Route53 DNS migration doesn't update txtOwnerId if there is an identical DNS Endpoint configured. The TXT record stays the same unless the DNS Endpoint is different or doesn't exist, which will attempt to delete the record (and fails) - AWS Route53 API reference:

To delete a resource record set, you must specify all the same values that you specified when you created it.

This is probably an issue as well but not really the focus of this issue.

What you expected to happen:
When migrating Azure DNS, even if the DNS Endpoint is identical, the TXT record's "owner" is updated to the new txtOwnerId. And if the DNS Endpoint is missing, it is deleted; if the DNS Endpoint is different, it is updated.

How to reproduce it (as minimally and precisely as possible):
Create the following DNS Endpoint in the first cluster with a unique txtOwnerId (e.g. cluster-1).

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: same-dnsendpoint
spec:
  endpoints:
    - dnsName: same.example.com
      recordTTL: 300
      recordType: CNAME
      targets:
        - target.com

Create the same DNS Endpoint in the second cluster with another txtOwnerId (e.g. cluster-2) and add the --migrate-from-txt-owner=cluster-1 flag.
Note: The domain must be hosted on AWS Route53.

Anything else we need to know?:

Environment:

• External-DNS version (use external-dns --version): Tested images v0.20.0, v0.21.0, v0.22.0
• DNS provider: AWS Route53
• Others:

Checklist

• I have searched existing issues and tried to find a fix myself
• I am using the latest release,
  or have checked the staging image to confirm the bug is still reproducible
• I have provided the actual process flags (not Helm values)
• I have provided kubectl get <resource> -o yaml output including status
• I have provided full external-dns debug logs
• I have described what DNS records exist and what I expected