Unable to inject Linkerd into Ambassador pod when custom Auth module is used

[bourquep]

Describe the bug

In order to allow the Linkerd proxy to be injected into the Ambassador pod and have the requests properly routed by Linkerd, we must add a custom l5d-dst-override header to our requests, as documented here.

This works well as long as Ambassador Auth module is not involved.

With an Auth module configured, Ambassador injects the l5d-dst-override header into the requests that are destined for the auth service, which tricks the Linkerd proxy into routing the auth request to the final upstream service, making all auth requests fail.

To Reproduce

• Install Ambassador
• Configure a custom Auth module
• Configure a mapping
• Test to make sure that calls made to Ambassador are properly authenticated (via auth service) then routed to the upstream service (via mapping).
• Install Linkerd with automatic proxy injection enabled
• Inject the Linkerd proxy into everything (either add the linkerd.io/inject: enabled annotation to all namespaces, or to all deployments (service, auth, ambassador).
• Add this to the Ambassador mapping:

     add_request_headers:
        l5d-dst-override: fully-qualified-service:port

• Observe that calls made to Ambassador don't work anymore - the authentication requests are routed to the upstream service, not the auth module.
• Disable the auth module
• Observe that calls work, they are properly routed to the upstream service

Expected behavior

One of:

• The headers configured via add_request_headers are not be added to the auth request
• The headers configured via add_request_headers can be configured to be added to the auth request or not
• The l5d-dst-override header is automatically added by Ambassador to all requests, setting the appropriate fully-qualified service address for each request (auth or otherwise)

Versions (please complete the following information):

• Ambassador: 0.70.1
• Kubernetes environment Azure AKS
• Version 1.11.9

Additional context

This issue may or may not be related to #921

[gsagula]

I'm currently working on #1594. I believe that we could use Envoy headers_to_add for this one.
https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/http/ext_authz/v2/ext_authz.proto#config-filter-http-ext-authz-v2-authorizationrequest