Support multiple stages in Application's `authorized-stage` annotation

[jessesuen]

Proposed Feature

Currently, the kargo.akuity.io/authorized-stage annotation that we set on an Application can only map to a single stage. This prevents multiple Stages from performing an argocd-update against the same application.

A long, long time ago, we actually used to support things like wildcards in kargo.akuity.io/authorized-stage, but had to be removed on performance & technical grounds.

One thing we need to check is whether we still rely on this annotation to optimize lookups for which stage/promotion to refresh when application health changes. If we do, then we may only be able to support explicit lists:

kargo.akuity.io/authorized-stage: project1:stage1,project1:stage2

but not wildcards:

kargo.akuity.io/authorized-stage: project1:*

NOTE: This issue has been raised before, but I am filing a new one because some of the previous discussion points are two years old and may no longer be relevant.

Motivation

There are use cases where stages don't necessarily represent an environment, but rather a process of their promotion pipeline.

[scott-hpe]

I was looking for this a few weeks ago. I didn’t need a wildcard, but I did need to target ArgoCD applications from two different Kargo stages.

We do frequent multi-region flips between a primary and secondary region.

In Kargo, I have a stage-primary and stage-seocndary defined. I dynamically map these Kargo stages to target ArgoCD applications on us-west-2 and us-east-2. Without the ability to allow for multiple Kargo stage annotation values, we need to use a script that updates all matching ArgoCD applications resources flipping those with stage-primary to stage-secondary. That work could be avoided by allowing for multiple Kargo stages to target an ArgoCD application.

[eddiewebb]

Issue was linked to Harvestr Discovery: Support multiple stages in Application's authorized-stage annotation