Signed-off-by: Martin Matusiak numerodix@gmail.com

Commit Message: router: consume all retry related headers
Additional Description: Update the router to consume all retry related headers, to prevent them being propagated to the upstream.
Risk Level: low
Testing: Added new unit tests & did manual testing (with the runtime feature both on and off).
Docs Changes: None
Release Notes: Added
Runtime guard: envoy.reloadable_features.consume_all_retry_headers

I was testing retries when I discovered what seems like a bug with the handling of retry headers. If I make a request setting lots of different retry related headers like so:

curl -v \
  -H 'x-envoy-retry-on: retriable-status-codes,retriable-header-names' \
  -H 'x-envoy-retriable-status-codes: 500' \
  -H 'x-envoy-retriable-header-names: X-Retry-Always' \
  -H 'x-envoy-max-retries: 2' \
  -H 'x-envoy-hedge-on-per-try-timeout: true' \
  -H 'x-envoy-upstream-rq-per-try-timeout-ms: 2' \
localhost:8080

:8080 is envoy proxying to a trivial http server that just echoes what it receives. What I'm seeing envoy send is:

host: localhost:8080
user-agent: curl/7.68.0
accept: */*
x-envoy-retriable-status-codes: 500
x-envoy-retriable-header-names: X-Retry-Always
x-forwarded-for: 192.168.1.110
x-forwarded-proto: http
x-envoy-internal: true
x-request-id: fdc5b240-d3e5-4ec3-8c2e-5ceaa15901eb
content-length: 0

Most of the x-envoy-XXX headers have been removed/consumed by the retry implementation, but x-envoy-retriable-status-codes and x-envoy-retriable-header-names have not.

I see two issues with this:

• This behavior does not seem "hygienic". Envoy is not ignoring these headers (eg. because they are untrusted, or because it doesn't think they are meant for itself), it is acting on them. But it is also letting them propagate.
• These headers could be used (inadvertently or intentionally) to control the "next" envoy. If upstream is also an envoy, and has configured retry_on: retriable_status_codes,retriable_header_names then its policy could be partly overridden.