Allow usage of "--force" to apply updates to KUDO managed resources

[ANeumann82]

As mentioned in #1332 that PR introduces a backwards incompatible change.

This issue tries to provide a solution to handle that issue and some others.

What would you like to be added:
A --force parameter to use on k kudo update

Why is this needed:
This would allow the apply task in KUDO to handle a failure while patching a resource. This failure can have multiple sources:

• An old resource that does not have the "kudo.dev/last-applied-configuration" annotation
• A conflict between the current resource and the modified resource that KUDO wants to apply
• (Potentially:) An update to the resource that can't be modified normally

This approach would mirror the handling of kubectl apply most closely.

It would require to add a new field on the InstanceSpec to specify that the last update to the parameter set is expected to be force-applied. When the instance controller starts the plan execution, it clears this flag and incorporates it into the current plan execution.

Old idea
Certain updates to resources are not allowed by k8s. The kubectl apply provides a --force flag to still deploy those changes. In the background it schedules a delete/create for this instead of applying a patch.

We could have the same flag on an "Apply" Task to allow disruptive updates to resources. At the moment the only way to update those attributes is to manually write an "update" plan that deletes and recreates the resources.

[porridge]

I'm not sure that adding a force flag is a good idea. My concern is that an operator developer might not be aware that this is in fact causing a delete+re-create - which has potentially undesired consequences such as cascading deletion.
Perhaps if we name the flag such that it's explicit... 🤔

[ANeumann82]

Another option would be to have the --force flag on the k kudo update level, and not in the operator itself. This would require the user to explicitly use it.

[porridge]

When the instance controller starts the plan execution, it clears this flag

Which flag? This is the first time a flag is being mentioned in this description.
Do you mean the field in the spec:

a new field on the InstanceSpec

?

In that case I think it would be quite surprising and contrary to established conventions, if a controller was to mutate the spec of a resource it manages.

[ANeumann82]

Yes, I meant the field.

And changing the spec... It's what's currently happens with the PlanExecution field in the InstanceSpec as well if I read that correct.

I do agree that it's a bit unconventional. Any other ideas to pass a one-off flag for a parameter update to the controller would be very welcome