DGS-23821 Default names and updated frozen/non-frozen workflow support

[Robert Yokota (rayokota)]

What

This PR adds the following requirements:

1. CREATE + schema implies frozen STRONG: When creating an association with a schema via createAssociation, the association is automatically set to lifecycle=STRONG and frozen=true.
   Explicitly setting lifecycle=WEAK or frozen=false with a schema is rejected.
2. UPDATE + schema requires STRONG: A schema can only be passed with a STRONG lifecycle for createOrUpdateAssociation. WEAK associations with schemas are rejected.
3. Default subject for STRONG associations on CREATE: If the subject is not provided and the association is STRONG (frozen or non-frozen), it defaults to
   :.{resourceNamespace}:{resourceName}-{associationType}. For CREATE, subject is required for WEAK associations. WEAK associations cannot use the default subject format.
4. Frozen STRONG must use default subject: Frozen associations must use the default subject format (:.{resourceNamespace}:{resourceName}-{associationType}). Custom subjects are
   rejected for frozen associations.
5. Frozen/non-frozen consistency at the resource level: All associations for a given resource must be consistently frozen or non-frozen. Creating a request with both frozen and
   non-frozen associations is rejected. Creating a frozen association on a resource with existing non-frozen associations (or vice versa) is rejected.
6. UPDATE allows null subject, lifecycle, and frozen: For UPDATE, only associationType is required (defaults to "value" if omitted). If an existing association exists, the server
   fills in subject from the existing association. If no existing association exists, the server applies CREATE defaults (schema→STRONG+frozen with default subject, otherwise lifecycle
   defaults to WEAK which requires explicit subject). STRONG with default subject cannot be changed to WEAK.

Checklist

Please answer the questions with Y, N or N/A if not applicable.

• [Y] Contains customer facing changes? Including API/behavior changes
• [N] Is this change gated behind config(s)?
  • List the config(s) needed to be set to enable this change
• [Y] Did you add sufficient unit test and/or integration test coverage for this PR?
  • If not, please explain why it is not required
• [N] Does this change require modifying existing system tests or adding new system tests?
  • If so, include tracking information for the system test changes
• [N] Must this be released together with other change(s), either in this repo or another one?
  • If so, please include the link(s) to the changes that must be released together

References

JIRA:

Test & Review

Open questions / Follow-ups

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}

[Xuelian Han (xhan-cflt)]

In the AlterConfig case, user can just change lifecycle by only specifying lifecycle in the request. The intention is to mutate the existing subject's lifecycle.

Since no subject presents in the request, this code will set default subject to it, which is likely to be different from the real associated subject.

[Robert Yokota (rayokota)]

Good point, I changed the error message to make it clear

"subject of association cannot be changed from '"                                                                                                    
      +                + association.getSubject() + "' to '" + unqualifiedSubject + "'

[Xuelian Han (xhan-cflt)]

Robert Yokota (@rayokota) Hi Robert, I am not sure if I followed your logic.

My question is that in the AlterConfig case, it is incremental alter config, so users are allowed to only specify properties they want to change, and leave the rest unspecified.

In the case where the user only specifies the new lifecycle , since the subject is absent from the request, our code:
"""
if (createOrUpdateOp.getSubject() == null) {
createOrUpdateOp.setSubject(defaultSubject);
}
"""
will always set it to the default subject, which we shouldn't. The subjects should be passed as null to the server and be resolved on server side based on the existing association. Does that make sense?

[sonarqube-confluent]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube