feat: create cli commands for ApplicationSet

[ishitasequeira]

Note on DCO:

If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the Details link next to the DCO action for instructions on how to resolve this.

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• Optional. My organization is added to USERS.md.
• I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green (troubleshooting builds).

[codecov]

Codecov Report

Merging #9584 (b329e4d) into master (9fac0f6) will decrease coverage by 0.38%.
The diff coverage is 17.30%.

@@            Coverage Diff             @@
##           master    #9584      +/-   ##
==========================================
- Coverage   45.69%   45.31%   -0.39%     
==========================================
  Files         234      236       +2     
  Lines       28508    28827     +319     
==========================================
+ Hits        13027    13063      +36     
- Misses      13694    13973     +279     
- Partials     1787     1791       +4     

Impacted Files	Coverage Δ
applicationset/controllers/clustereventhandler.go	69.56% <ø> (ø)
applicationset/generators/cluster.go	77.90% <ø> (ø)
applicationset/generators/duck_type.go	68.62% <ø> (ø)
...licationset/generators/generator_spec_processor.go	61.64% <ø> (ø)
applicationset/generators/git.go	85.96% <ø> (ø)
applicationset/generators/list.go	62.50% <ø> (ø)
applicationset/generators/matrix.go	70.73% <ø> (ø)
applicationset/generators/merge.go	59.04% <ø> (ø)
applicationset/generators/pull_request.go	42.85% <ø> (ø)
applicationset/generators/scm_provider.go	35.23% <ø> (ø)
... and 19 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[crenshaw-dev]

So I think the big question we have to answer is: should we require all write-type ApplicationSet API requests to have an un-templated spec.template.spec.project field, or can we accept templated Project fields?

I think when @leoluz and @ishitasequeira and @jgwest and I discussed it last, we had settled on disallowing write-type API requests when the AppSet Project field was templated. But I think we can eliminate that requirement.

My proposal:

1. Before each RBAC check, run fasttemplate over the Project field and replace each template with an asterisk.
2. Perform the RBAC check for the now-templated project fields.

For example, suppose I have RBAC like this:

p, appset-dev-maintainers, applicationsets, update, *-dev/*, allow

If a user tries to update an AppSet like this:

metadata:
  name: apis-appset
spec:
  template:
    spec:
      project: "{{path[0]}}-dev"

Then the following RBAC check would happen:

*-dev/apis-appset # passes because it matches the first rule

I don't think this would be too much additional code, and I think it would make the API support for ApplicationSets much more powerful. Thoughts?

[crenshaw-dev]

After chatting with Leo... ignore my last comment, I think that can be introduced in a later PR. For now, let's just reject AppSet API requests where the project field is templated.

[crenshaw-dev]

The other comment I had was that maybe we should just skip the Application RBAC checks and instead document very thoroughly that granting write capabilities on applicationsets grants the ability to do a bunch of things with applications by proxy.

[crenshaw-dev]

Ran into a few issues while testing the CLI.

[crenshaw-dev]

lgtm, thanks @ishitasequeira for putting so much work into this!

@jannfis do you want to give it another pass before merging?

[renperez-cpi]

@ishitasequeira thank you for this. do you know when this pr will be merged? would love to give this a spin :)

[jannfis]

LGTM. Thanks @ishitasequeira!

And thanks @crenshaw-dev for giving me opportunity to look over it again!