Migrate to go-yaml fork

[natasha41575]

kubernetes-sigs/yaml#76 is merged now, so we can use the upstream yaml fork now.

#5412 gets rid of our internal one and uses the new fork of go-yaml.v3.

However, we are still using go-yaml.v2 in some places (see the dependency here); we should migrate to using the upstream fork instead.

[prashantrewar]

replacing gopkg.in/yaml.v2 v2.4.0 with gopkg.in/yaml.v3 v3.0.1 is this right?

[natasha41575]

@prashantrewar No, we want to remove our dependency on gopkg.in/yaml libraries completely. Replace gopkg.in/yaml.v2 v2.4.0 with the new fork that kubernetes-sigs/yaml#76 introduced in sigs.k8s.yaml/goyaml.v2 1.4.0

[prashantrewar]

/assign

[shapirus]

I suggest benchmarking kustomize before and after the change to make sure that the new fork doesn't destroy performance :)

I can help with this once the change is made or when it is available in a branch.

[natasha41575]

@shapirus Please feel free to help with benchmarking (always happy to have performance tests). That said, I would be very surprised if this change impacted kustomize performance as the upstream fork's code is identical to what we are using in kustomize today, it just lives in a different place now.

[natasha41575]

Adding the PR here for easy tracking: #5421

[shapirus]

Meanwhile, I can confirm (using my tests described in #5422) that PR #5421 does not introduce any performance degradation compared to release v5.2.1.

p.s. it would actually be nice to have performance regression testing as part of CI. My tests can be used almost as is for that, except that they can't into fetching specific PRs. This however can easily be added with github cli which has a specific command to "checkout a PR". If someone decides to add such a test step in the CI workflow, feel free to use and modify my scripts in any way you need for that.