Bug: WaitTask waits for filtered resources

[karlkfi]

WaitTask currently ignores failed applies and failed prunes, but doesn't ignore resources skipped by filters in the ApplyTask or WaitTask.

Because WaitTasks are only added when there are dependencies (depends-on, CRDs, namespaces, etc.), this hasn't been much of a problem yet, but when using a sufficiently large/complex set of resources, it's feasible for the WaitTask to wait until timeout and fail because it's waiting for one of the following:

• [deletion prevention, inventory policy, local namespace] Expecting a delete that was skipped to cause that object to become NotFound
• [inventory policy] Expecting an apply that was skipped to cause the object (previously different or broken) to become Current

Suggested fix:

• Add tracking of skipped deletions and applies to the TaskContext (similar to the existing deletion tracking)
• Update WaitTask to ignore skipped deletions and applies

[karlkfi]

Blocks #438 & #449

[karlkfi]

Looks like apply filters are captured as failures. So that case might not actually be a problem (just confusing naming overlap).
https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/apply/task/apply_task.go#L137

Looks like prune filter are also captured as failures, except in the case of PreventRemoveFilterName where the inventory annotation is successfully removed. I don't know why this case is not captured. The logic around it is perplexingly complex with no comment as to why. Fixing it may cause a regression, if it was deliberate.
https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/apply/prune/prune.go#L134

[karlkfi]

The complex logic around whether to mark as a failed apply was added recently in #424

It looks like the failed applies are checked in the InvSetTask and kept in the inventory.
https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/apply/task/inv_set_task.go#L50

So changing it to track the deletion might change inventory behavior in the deletion prevention use case.

[haiyanmeng]

The reason for not calling taskContext.CapturePruneFailure when removeInventoryAnnotation succeeded is that TaskContext.pruneFailures are added into the inventory in the InvSetTask.

[karlkfi]

Gotcha, yeah. We're gonna need to find another solution, because the wait needs to be skipped, and the taskContext.CapturePruneFailure is what was telling the WaitTask to skip that object.

[karlkfi]

Fix: #456