ext_authz to be able to set x-envoy-force-trace

*Title*: *ext_authz to be able to set x-envoy-force-trace*

*Description*:
>The [documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-envoy-force-trace) states that
>>If an internal request sets this header, Envoy will modify the generated [x-request-id](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-request-id) such that it forces traces to be collected.
>
> However, setting this in an `ext_authz` with `allowed_upstream_headers` doesn't enable tracing. It does cause an `x-request-id` response header.
>
> It would be practical if `ext_authz` could set the tracing state based on user/session configuration since it's already manipulating that data anyway.

*Relevant Links*:
> The code that checks the header is in [conn_manager_utility.cc](https://github.com/envoyproxy/envoy/blob/b67a3fc250cd9f74fde744d400d7c6857ea80dea/source/common/http/conn_manager_utility.cc#L343), but I wonder if [this condition in conn_manager_impl.cc](https://github.com/envoyproxy/envoy/blob/075935f6f2fc87168a48f89992309c3ea6b6068f/source/common/http/conn_manager_impl.cc#L1062) is what's causing this decision to be re-evaluated after `ext_authz`.
>
> The `x-request-id` response header decision doesn't check the trace reason, but [explicitly looks at the force header](https://github.com/envoyproxy/envoy/blob/b67a3fc250cd9f74fde744d400d7c6857ea80dea/source/common/http/conn_manager_utility.cc#L493), which explains why that shows up even without tracing.