(ExternalName) Entitlement Add full `external-name` support

[enrico-kaack-comp]

Entitlement MR has no support for external name now.
We need to set it during Create and use it for matching during observe.

apiVersion: account.btp.sap.crossplane.io/v1alpha1
kind: Entitlement
metadata:
  name: msq-entitlement
  annotations:
    crossplane.io/external-name: "<subaccount_id>,<service_name>,<plan_name>" 
spec:
  forProvider:
    serviceName: message-queuing
    servicePlanName: standard
    amount: 1
    subaccountRef:
      name: my-subaccount
  providerConfigRef:
    name: account-provider-config

Composite Key

• Semantic match: serviceName, servicePlanName, per subaccount (ID of subaccount)

Acceptance Criteria

• Create sets the external-name to the external identifier (composite key)
• Observe uses the external-name annotation as primary matching key so the initial observe would match an existing resource even if it was not created in a previous reconcile of the provider
• Unit test tests the external-name matching behaviou
• we do not require the forProvider spec to be filled than

[GenosseOtt]

Lets be inspired by our friends from Terraform Team
https://registry.terraform.io/providers/SAP/btp/latest/docs/resources/subaccount_entitlement#import

[dattito]

Currently for one ServicePlan of a Service, multiple entitlements can be created, and the amounts of all Entitlement CRs will be merged.

After the external-name change, the identifier is dependend on the ServicePlan, this means that it would no longer be possible to create multiple Entitlement CRs for one ServicePlan.

This would be a breaking change.

We now have to think about how to continue.

---

CC @enrico-kaack-comp

[dattito]

Current status:

• Multiple entitlement CRs can be created for one "<subaccount_id>,<service_name>,<plan_name>" combination.
• At reconcilation, each entitlement CR lists all other entitlement Crs, merges their spec and sends a request to the BTP server. This is done by every CR, leading to a ratelimit
• This violates the guideline that the resources should be independent
• For external name support, "<subaccount_id>,<service_name>,<plan_name>" should be the new external-name identifier for the resource (just like in the BTP TF provider). This means that it would no longer be possible to have multiple entitlement CRs for one of these combinations, leading to a breaking change if we'd change it.
• [Spike] Optimization of Entitlement: many network requests #256

Proposal:

• Creating a new Entitlement v1alpha2 CRD, that has "<subaccount_id>,<service_name>,<plan_name>" for the external-name and is unique for this combination. It complains if another entitlement for the same plan already exists.

---

CC @enrico-kaack-comp @dwlou

[dwlou]

I do not see the need to allow several CRs to manage the entitlement of the same service+plan in the same subaccount. it just not make sense semantically. On the other hand, if nothing else is changes, why it is not possible multiple CRs with the same external-name?

[dattito]

Multiple CRs should not have the same CR because the external-name is also used for importing of resources. This means that the current state that the controller resolves during the observation should only depend on the external-name annotation. If multiple CRs target the same resource, you cannot figure out which quota was allowed by which entitlement CR.

[dattito]

If there should not be a v1alpha2 resource, then a dirty way could be to make this allowance count also part of the external-name.