A user can only update an ApplicationSet if the user has permission to create, update, delete all of the Applications currently owned by the ApplicationSet.

• When the user makes a change to an ApplicationSet, we assume that it's possible that the change might affect any or all of the Applications, and thus we require the user to have write access to all of those Applications.
• We likewise check that the resulting generated Applications are also compliant with the user's permissions.

Algorithm is, if the user attempts to update an ApplicationSet via Web UI/CLI:

• ApplicationSet controller receives a request to update an ApplicationSet from API server
• The ApplicationSetController looks at all the Applications owned by the ApplicationSet (via ownerref or annotation): Verify that the user has permission to act on all of the Applications currently managed by the ApplicationSet
• If the above precondition is met, proceed to the next step, otherwise fail.
• The ApplicationSet is generated and rendered into a template
  • Look at the generated Applications, and make sure the user has appropriate privileges
    • All the same checks done by the Create workflow, described above, are done here (user can access repo, cluster, etc
• Finally, on success, the API server applies (kubectl apply) the requested change to the ApplicationSet (and the Applications).

Acceptance Criteria:

• `argocd appset update` command works successfully
• ApplicationSet and respective Applications are updated successfully