add kustomize edit add generator command

[natasha41575]

Fix #4343

Per request, create a command kustomize edit add generator. Just like the existing kustomize edit add transformer, but for generators. This code is almost identical to the code in addtransformer.go and addtransormer_test.go.

/cc @KnVerey
/cc @yuwenma

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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:

• OWNERS [natasha41575]

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

[yuwenma]

Suggest to add validation to make sure

• The existence of the path. Reason: if not checked, kustomize build will fail for the same reason anyway. it makes kustomize edit feel less reliable/stable since it edits user files without necessary validation checks even the same logic is used in kustomize build.
• Format of the generator. Reason: whoever uses kustomize edit is more expecting kustomize to give guidance and validation checks. Thus, validation checks like valid yaml, valid OpenApi could always be super helpful. We can add a TODO here if not planning to add the validation check for now. But overall I feel like expanding the validation checks on kustomize edit is a good approach to introduce users to rely more on this command.

[yuwenma]

ah, I saw the GlobPatterns below.

[natasha41575]

To your first point, yeah the validation of the path is done in GlobPatterns. But I think it makes more sense to do that step in Validate, so I've moved it over.v

For the second point, I think that's a good idea but would be better in its own PR, so I added a TODO.

[yuwenma]

sg.

[yuwenma]

/lgtm
👍 for the transformer rewording.

[ephesused]

Edited to add:

The below analysis is incorrect. This PR is not the cause of the sorting change described in the remainder of this comment.

---

For awareness, this commit slightly alters name sorting for resources. Previously (ff7b2f2) kustomize would order like so:

1. testing
2. testing-one
3. testing-two

With this change (92197fd) kustomize orders like so:

1. testing-one
2. testing-two
3. testing

Test case files

kustomization.yaml:

resources:
  - resources.yaml

resources.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: testing
data:
  key: value
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: testing-one
data:
  key: value
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: testing-two
data:
  key: value

[KnVerey]

@ephesused can you please open an issue with reproduction steps including Kustomize versions. A change in order is concerning, but I don't think this PR could have caused it. It is unreleased, and only affects a command that helps you author the Kustomization itself; it does not affect Kustomize buid.

[ephesused]

I'll open a separate issue, but this isn't an change I'm seeing in any releases. I'm seeing the difference on the master branch, between commits ff7b2f2 and 92197fd. I had thought 92197fd was this PR.