Add support for configuring arbitrary provider-specific properties via annotations

[Dadeos-Menlo]

Description

Support for provider-specific annotations, that manifest as Endpoint.ProviderSpecific properties, is currently restricted to a subset of pre-defined providers. This functionality should be available to all providers, without requirement for special-case registration within the getProviderSpecificAnnotations(…) function.

The proposed changes include:

• Inversion of logic within the getProviderSpecificAnnotations(…) function so as to treat all annotations prefixed with external-dns.alpha.kubernetes.io/, but that are not otherwise recognised, as provider-specific properties

Notes:

• The existing allocation of annotations (i.e. whether they might be considered provider-specific or not) is somewhat unfortunate; but it is appreciated that any efforts to tidy-up annotations are likely constrained by concerns regarding backwards-compatibility
• It is assumed that the naming of provider-specific properties (i.e. whether they should be of the form provider/property or provider-property) is an internal implementation detail, and therefore the proposed renaming does not represent any backwards-incompatibility
• The documented suggestion for adopting annotations of the form …/webhook-<custom-annotation> is considered unwise - provider-specific properties are considered to be provider-specific, whereas the Webhook provider is considered to be a wrapper of providers, rather than a provider in and of itself (see: Moving providers out of tree #4347)
  • The renaming of Webhook related provider-specific properties (i.e. from webhook-property to webhook/property has not been implemented - implementation would be trivial, but given the conclusion that provider-specific properties associated with a Webhook provider are nonsensical, such an implementation is not being initially proposed
    • It is not clear to me, but seems unlikely, that anyone will have adopted the Webhook framework and are relying upon provider-specific properties

Checklist

• Unit tests updated
• End user documentation updated

[k8s-ci-robot]

Hi @Dadeos-Menlo. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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.

[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 szuecs for approval. For more information see the Kubernetes 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