Handle "Result" errors as non-fatal errors in kyaml FilterFuncs

[Goodwine]

Context & Description

kyaml currently has no way of updating ResourceList.Result unless a custom processor is created by the end user.
This PR updates ResourceList.Filter used by all current processors so whenever the kio.Filter returns an error type *Result it will be assigned to ResourceList.Result instead of erroring out as is the current behavior.

This behavior change in ResourceList.Filter is a breaking change in the API, I believe this should be OK because IIUC this use case is not adopted widely.

Alternative Considered

Instead of special error handling, we can introduce a new Resulter{ Result(...) (*Result, error) } interface that can be implemented by the KRM's Filter(), but when trying this out it feels very non-idiomatic because in most cases where we want a Resulter we would also have a no-op filter like func (myExample) Filter(in) { return in, nil }.

This is also an extra things to be kept in mind from KRM function authors because the interface is not explicitly called out and the behaviors can be unexpected and non idiomatic.

However this does avoid the breaking change.

Workaround
Introduce a new value in Result.Severity called Fatal, the ResourceList.Filter function could verify this value when applicable and throw an actual error instead of keep going.
(Or.. we can make erroring out the default behavior but adding a new Result.NoError flag to trigger this new behavior.

Additional Notes

• This PR is built on top of PR Fix kyaml readwriter inconsistencies when wrapping resources #4235, the first 2 commits are not part of this change.
• I also have a function/example that goes with this change but is blocked by this PR being merged because of go-modules
• This change has been discussed briefly with Katrina Verey and Jeremy Rickard (in case this needs to be discussed in a Kustomize meeting)

[k8s-ci-robot]

@Goodwine: This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

Hi @Goodwine. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Goodwine]

/assign @KnVerey

[Goodwine]

When looking at the behavior changes needed here I realized that not all processors behaved the same with Filter when Results was returned as an error value, e.g. kio.Pipeline so I went ahead and updated all invocations to handle the results gracefully so it's not only the ResourceListProcessor but also the others, and this required untangling dependencies, especifically moving Results from the framework package into kio

This is quite a change so I'll wait to discuss this further this week

[Goodwine]

After discussing with Katrina over slack we reached out conclusion that the original PR was OK, we don't need to overreach with Results since it's ResourceList-specific

The only 2 key things worth mentioning are

• kio.Pipeline doesn't collect the results and if this is a wanted behavior a framework.Pipeline could be added in the future but probably not needed in this PR.
• the runtime package that has starlark code generation for a ResourceList doesn't handle Results either and that is out of scope for this PR

[KnVerey]

/lgtm
/hold for @natasha41575 to approve

[KnVerey]

/lgtm

[KnVerey]

/ok-to-test

[natasha41575]

So sorry for the delay!

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Goodwine, natasha41575

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• kyaml/OWNERS [natasha41575]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment