Describe the bug

For v2.2, we will start support for annotation-based resource tracking (instead of labels), which allows us to track which objects "belong" to an application without the character limit. Proposal:

https://github.com/argoproj/argo-cd/blob/d823efee5d16837258bc151a3a5c59671f02509d/docs/proposals/application-name-identifier.md

However, I noticed in the proposal, I noticed we are still using app.kubernetes.io/instance as the annotation key. I think it's inappropriate to use that as a key name since:

1. app.kubernetes.io/instance is a Kubernetes standard/recommended label for an application instance, and now we are using it as an annotation. So I think it is weird to use a well-known label as an annotation and will be confusing to some.
2. the content of app.kubernetes.io/instance annotation is no longer homogeneous across all resources associated with the application because it now includes the resource id (kind, name, namespace). So it breaks the meaning of app.kubernetes.io/instance since each resource will have different values
3. this is our opportunity to fixate on a new, standard, key name that users cannot override. Currently, the community maintained helm chart is using a different tracking id than the kustomize based install manifests. We can get both install versions back on the same page.

I suggest something like argocd.argoproj.io/tracking-id:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  namespace: default
  annotations:
    argocd.argoproj.io/tracking-id: my-application:apps/Deployment:default/my-deployment

Version

Unreleased v2.2