Support for gRPC retries based on trailers

I have an application that uses gRPC for bidirectional client <-> server communication which passes through envoy. I spent some time trying to set up a configuration where I made use of `x-envoy-retry-grpc-on` with a value of `deadline-exceeded`, however this does not appear to work as far as I can tell.

I found this previous issue that looked like a similar problem but I wasn't able to find anything there that helped me resolve my problem: https://github.com/envoyproxy/envoy/issues/7413

The last comment on that issue is exactly what I'm hoping to get clarification on. From what I can tell gRPC always sends `grpc-status` as a trailer and does not send it as a response header. In the bidirectional streaming case, gRPC will send back response headers and then data will continue to flow back to the client until the connection is closed and the trailers are sent.

This effectively makes the gRPC retries non-functional for streaming use-cases unless I'm misunderstanding or possibly have this misconfigured?

Ideally I would like to configure a deadline in my server that will cause the connection to reconnect without propagating all the way back to the client. This is an attempt to help resolve load balancing issues for these long-lived streaming gRPC connections.