update docs

Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>

docs/features/traffic-management/nginx.md

@@ -34,6 +34,7 @@ spec:
           additionalIngressAnnotations:   # optional
             canary-by-header: X-Canary
             canary-by-header-value: iwantsit
+          canaryIngressAnnotations:     # optional
             my-custom-annotation.mygroup.com/key: value
 ```
 
@@ -43,9 +44,8 @@ The controller routes traffic to the canary Service by creating a second Ingress
 
 Since the Nginx Ingress controller allows users to configure the annotation prefix used by the Ingress controller, Rollouts can specify the optional `annotationPrefix` field. The canary Ingress uses that prefix instead of the default `nginx.ingress.kubernetes.io` if the field set.
 
-**There is an exception** to this behaviour: if an annotation an annotation under `additionalIngressAnnotations` already has a prefix (a prefix is considered to be defined if there is a slash (`/`) separator in the annotation key, [as defined in the Kubernetes docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set)), it will not be overriden.
-Looking at the example above, `my-custom-annotation.mygroup.com/key` would not be prefixed with the configured `annotationPrefix` in the generated Ingress object.
-
+If full annotations, [as defined in the Kubernetes docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set),perhaps from different groups, need to be declared, the `canaryIngressAnnotations` field can be used instead, which accepts a similar key-value structure, but performs no prefix injection.
+Note that, in case of collision with `additionalIngressAnnotations`, the value under `canaryIngressAnnotations` prevails.
 
 ## Using Argo Rollouts with multiple NGINX ingress controllers per service
 Starting with v1.5, argo rollouts supports multiple Nginx ingress controllers pointing at one service with canary deployments. If only one ingress controller is needed, utilize the existing key `stableIngress`. If multiple ingress controllers are needed (e.g., separating internal vs external traffic), use the key `stableIngresses` instead. It takes an array of string values that are the names of the ingress controllers. Canary steps are applied identically across all ingress controllers.