[Bug] error with top_level variable after version update

[FelixMMS]

Description

after updating collection Version from 3.2.0 to 4.3.2 the variable subject_alt_name.top_level produces an error in the task for the azure acme_challenge_provider.

Reproduction steps

Run this task:

  tasks:
    - name: Create and upload Lets Encrypt certificate for <DOMAIN>
      ansible.builtin.include_role:
        name: telekom_mms.acme.acme
        public: true
      vars:
        acme_challenge_provider: azure
        acme_domain:
          email_address: "{{ service_email }}"
          certificate_name: <CERT_NAME>
          zone: "<ZONE>"
          subject_alt_name:
            top_level:
              - "<DOMAIN>"
              - "*.<DOMAIN>"

Current Behavior

TASK [telekom_mms.acme.acme : Handle challenge data] ***************************
fatal: [127.0.0.1]: FAILED! => 
  msg: 'Expected dns-01 challenges for the following domains not found: top_level // The API responded with dns-01 challenges for the following domains we did not expect: *<DOMAIN>,<DOMAIN>'

Expected Behavior

Create the certificate. The Handle challenge data Task wasnt there in the older version.

TASK [telekom_mms.acme.acme : Create a challenge using a account key file for wildcard-<DOMAIN>] ***
changed: [127.0.0.1]
TASK [telekom_mms.acme.acme : Do challenge with provider azure] ****************
included: /root/.ansible/collections/ansible_collections/telekom_mms/acme/roles/acme/tasks/challenge/dns-01/azure.yml for 127.0.0.1
TASK [telekom_mms.acme.acme : Add a new TXT record to the SAN top-level domains] ***
changed: [127.0.0.1] => (item=<DOMAIN>)
changed: [127.0.0.1] => (item=*.<DOMAIN>)

Additional information

The change is probably in this commit
8928cf8#diff-cc89a63fb2808a76662639f4c04c498ef1d007ccb232f16a6a92a3bb127085ea

[neubi4]

The newly added find_challenges filter breaks here because the Azure DNS-01 provider works a bit different to our other providers.

All other proividers use acme_domain.zone to define which zone should be used.

The Azure DNS-01 provider does not use the acme_domain.zone variable but an rather difficult to understand config option with acme_domain.subject_alt_name.top_level and acme_domain.subject_alt_name.second_level which then use complex code to generate the DNS records: azure.yml#L6

I am not quite sure why this approach is used in the azure provider. In the example it seems to be an workaround for domains like .co.uk.

My suggestion is to simplify Azure DNS-01 provider to use acme_domain.zone and strip top_level and second_level. It would then be compatible to our other providers.

The downside of this approach is that you can only have certificates with domains in one domain zone, so domain1.example.com and domain1.example.co.uk in an single SAN cert is no longer possible.

But all our other providers also does not support multiple zones at the moment.