Supply x-envoy-downstream-service-node HTTP header to the upstream when needed

[RomanDzhabarov]

This works similar to the x-envoy-downstream-cluster-name and can be used for various purposes by upstream.

[htuch]

@RomanDzhabarov The implementation LGTM, but I'm curious why you went for a fixed x-envoy-downstream-canary header instead of x-envoy-downstream-service-node, i.e. it seems this loses information. Is there some internal upstream expectation that treats this header specially?

Out of the scope of this PR, I was thinking this might be another use for #1016 if we had %SERVICE_NODE% as a header variable.

[RomanDzhabarov]

@htuch The use case we have in mind is to have fault filters on the upstream ingress and do fault injections only for canary downstream nodes. I need to detect whether downstream is canary or not (so I wanted to be explicit).
x-envoy-downstream-service-node certainly covers this scenario, but also we have XFF which can help to identify the downstream IP etc (if we care about specific node id).

I can proceed, either way, let me know.

[htuch]

I'm wondering whether using a fixed canary value for node ID here is overloading the node name concept. It seems that service-node is used to identify a node uniquely for the purposes of API fetch (e.g. CDS, RDS). Will there always be a single canary node or might there be canary-0, canary-1, etc?

[RomanDzhabarov]

I'd vote that canary is not just a single node, we should not base our assumption on having just one canary.

Here is what i think would be better to satisfy our needs.
Pass service-node and then on the ingress side make sure that the right expectations are set wrt to canaries.

I'll do a change shortly.