As a developer, I want to have propagation from the labels that I set on my Ingress to the generated route resource, so I can add metadata that can help me keeping track of the resource, knowing that all labels on my child route resource will be replaced.

As a developer, I want to have propagation from the labels that I set on my Ingress to the generated route resource, so I can control specific behavior that depends of labels, from the parent Ingress resource, knowing that all labels on my child route resource will be replaced.

As a developer, I want to opt-in on the label propagation behavior, so I wont be surprised by a new behavior that will overwrite all of my existing labels

----- 

Story details:

Our controller already implements annotation propagation from Ingress to Route (https://github.com/openshift/route-controller-manager/blob/c337cf413bbbfc2154dc1d3c1bf8007ea1edfbc8/pkg/route/ingress/ingress.go#L511). This same behavior is not available for labels added to Ingress resource, which causes confusion on users willing to have the same behavior, as also causes problems on when an ingress is updated/recreated that existing labels on routes don't exist anymore.

This implementation/story is composed of the following steps:

• Define an annotation that will serve as opt-in for this feature, and that should be set on an Ingress resource - PM suggestion is route.openshift.io/reconcile-labels with value true{}
• During the reconciliation of an Ingress resource:
  • In case the annotation is not present, no label should be synced to route resource
  • In case the annotation is present and the value is "true", the labels on the route resource should be replaced by the same labels from the parent ingress resource
  • In case the annotation is further disabled, the propagation will stop happening and the existing labels on route resource will be kept but no further update will happen
  • In case the annotation is re-enabled, the propagation should happen again
  • Execute the workflow above for both "create" and "update" of an Ingress resource

From the description above, the expected tests should be implemented:

• Unit tests for the workflow above
• An e2e test (on Origin right now, as OTE is not available) to guarantee that the behavior happens as expected