Do not overwrite X-Request-ID header

**Community Note**
* Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

App Runner currently overwrites the `X-Request-ID` header if sent by the HTTP client with it's own value and then forwards that to the service running in App Runner.

This is confusing and makes tracing an HTTP request from client to backend and back to the client impossible using this header.

`X-Request-ID` is a "defacto" standard header that should be respected by any "middleware" and passed upstream without modification.

If AWS need a header to help them manage their App Runner infrastructure they should use a header namespaced for internal use only. There are many examples of this with other AWS services, such as `x-amzn-trace-id`.

**Describe alternatives you've considered**

The alternative would be for everyone else to use a different header, such as `X-Correlation-ID` or something company specific and hope that AWS don't start overwriting that one too. 🙄

This is potentially extremely disruptive and may not even be possible for some legacy systems.

**Additional context**

Changing the behaviour of the Envoy proxy to support this is a simple configuration change which should be the default for Envoy but for backward-compatibility reasons they decided not to make it so.

> preserve_external_request_id
([bool](https://developers.google.com/protocol-buffers/docs/proto#scalar)) Whether the connection manager will keep the [x-request-id](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-request-id) header if passed for a request that is edge (Edge request is the request from external clients to front Envoy) and not reset it, which is the current Envoy behaviour. This defaults to false.

[Envoy Docs](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#:~:text=can%20be%20disabled.-,preserve_external_request_id,-(bool)%20Whether%20the)

**Attachments**

none