RBAC Documentation improvements

[spencergilbert]

Summary

Improve documentation around RBAC configuration. The current documentation doesn't go into detail on what each "action" does.

Motivation

Without checking the source code/tests (and even after) it wasn't clear to me what the action action would give permissions to. Similarly for update vs override, and while override is mentioned on another documentation page the information should be centralized for discoverability.

Proposal

Write down the knowledge 😄

Copied reponse from @jessesuen in slack channel

Actions are the customized actions you can define for a resource. We have a built-in “restart” action for Deployments, StatefulSets, which simply update a pod template annotation. We also have a built-in “resume” action for Rollouts which will unpause the Argo Rollout.
These actions are not grated by default, and must use the RBAC rules to give these actions to users.

p, role:tech, applications, action/*, example/*, allow
p, role:tech, applications, action/apps/Deployment/restart, example/*, allow

[dbeckham]

An additional issue related to RBAC documentation is that the comments in the example argocd-cm-rbac.yaml ConfigMap file do not match the RBAC documentation

Specifically the policy rule form in the ConfigMap file:
p, subject, resource, action, object, effect

Does not match the one in the documenation:
p, <role/user/group>, <resource>, <action>, <object>

There is no mention of "effect" in the online documentation.

[agaudreault]

Closed by #18124