Set last-applied-label during create or replace operation atomically

[timothysmith0609]

Replaces #971

For resources that are BOTH

• Created via create and/or replace
• Prunable

krane currently first issues the create/replace command, then subsequently calls apply. This is done to ensure ongoing cleanup of resources like DB-Migrate pods that would otherwise just hang around.

Unfortunately, this subsequent apply breaks if a mutating admission controller modified an otherwise immutable field. The document presented by krane now conflicts with the API server and the deploy fails.

Thankfully, kubectl supports adding the last-applied-configuration annotation (which is the signal used by k8s to marks resources as prunable). Using the exact same logic we were using to add individual resources to the applyables list, we can just conditionally set the --save-config flag on kubectl create/replace

EDIT: I had to bend over backwards a bit further than I first thought to get this working. The intent with this behaviour is to clean up created/replaced resources from the LAST deployment that has occurred. After fighting trying to get no-op server-side applies to work (the documentation does not match the behaviour), I've been forced to conditionally set last-applied-configuration annotations on created resources in the Deploy all Resources phase. This entails adding a conditional parameter for whether or not to annotate individual resources, since this code path is used by both the Predeploy Priority Resources and Deploy all Resources steps

This does introduce a subtle failure mode. If the apply_all succeeds but annotate_individuals fails, the individual resources will never be tagged and thus not subject to pruning on the subsequent deploy.

[jpfourny]

Nice!

[timothysmith0609]

This does introduce a subtle failure mode. If the apply_all succeeds but annotate_individuals fails, the individual resources will never be tagged and thus not subject to pruning on the subsequent deploy.

This issue actually already exists, though in a slightly narrower scope, today. If the apply fails, subsequent krane deploy of a different set of documents would also cause 'orphaned' (I'm using the term very loosely) resources.