Add possibility to cascade force delete connect cluster & connectors

[AfrinKhan02]

Context

When deleting a connect cluster, the existing --force option only removes the cluster from Ns4Kafka without touching the connectors on the actual Connect cluster. There was no way to perform a clean end-to-end removal that also deletes the related connectors - both from the real Connect cluster and from Ns4Kafka's records.

This PR introduces a --cascade flag that enables cascading deletion of connectors when deleting a connect cluster, complementing the existing --force flag. Used together (--cascade --force), they handle the case where the Connect cluster is unreachable but you still want to clean up Ns4Kafka's state.

The behavior matrix is summarized below:

Option	Connectors exist?	Connect reachable?	Result
FORCE	Ignored	Ignored	Deletes only the connect cluster from Ns4Kafka. Connectors remain both on the actual Connect cluster and in Ns4Kafka's records.
CASCADE	Yes	Yes → deletes connectors from Connect + Ns4Kafka, then deletes connect cluster	Works end-to-end: clean removal of everything.
CASCADE	Yes	No → ERROR	Refuses. It won't remove connectors from Ns4Kafka if it can't also remove them from the real Connect cluster, because that would create a silent inconsistency.
CASCADE+FORCE	Yes	Yes → deletes connectors from Connect + Ns4Kafka, then deletes connect cluster	Same as CASCADE when things are healthy.
CASCADE+FORCE	Yes	No → skips Connect deletion, still deletes connectors from Ns4Kafka + deletes connect cluster	Accepts that the real Connect cluster is unreachable and cleans up Ns4Kafka's state anyway. Mainly for when the Connect cluster is already gone/broken.

Proposed solution

Add a new --cascade CLI flag to the delete command that is forwarded as a query parameter to the Ns4Kafka API, enabling server-side cascading deletion logic.

Implementation

• Delete.java - Added --cascade option (boolean flag), wired into the delete call alongside the existing --force flag.
• NamespacedResourceClient.java - Extended the @Delete URI template and method signature to include the cascade query parameter.
• ResourceService.java - Propagated the new cascade parameter through the delete method to the namespaced client call.
• README.md - Updated CLI usage, option descriptions, and added example commands for --cascade and --cascade --force.

Tests

• DeleteTest.java

  • shouldCascadeDeleteConnectClusterByName - Verifies --cascade passes cascade=true, force=false.
  • shouldCascadeForceDeleteConnectClusterByName - Verifies --cascade --force passes both flags as true.
  • Updated all existing mock signatures to include the new anyBoolean() / eq(false) for the cascade parameter.

• ResourceServiceTest.java

  • shouldCascadeDeleteConnectCluster - Verifies cascade-only deletion at the service layer.
  • shouldForceCascadeDeleteConnectCluster - Verifies force+cascade deletion at the service layer.
  • shouldPassForceCascadeForUnsupportedResource - Verifies that force and cascade flags are transparently forwarded even for resource types that don't support them (e.g., Topic).

Remarks

• For the Ns4Kafka server-side changes that handle the cascade logic, please refer to ns4kafka#765.
• For the force delete changes on the kafkactl side, please refer to kafkactl#346.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[loicgreffier]

@AfrinKhan02 Here is my review. Just one small remark. Could you please rebase the PR?

[loicgreffier]

I think the DeleteMode wrapper enum is unnecessary. We can just forward the force and cascade options as-is.