Log timeouts when DP responds with timedout

[FullyTyped]

• base test impl
• test-impl

📬 Issue #, if available:

✍️ Description of changes:

In concurrent execution, when the runtime times-out, Dataplane will not stop the execution, but instead will inform the runtime through the trailers that we've timed-out when we respond. This PR intends to consume the trailers to ensure that in those scenarios the runtime correctly logs.

🔏 By submitting this pull request

• I confirm that I've ran cargo +nightly fmt.
• I confirm that I've ran cargo clippy --fix.
• I confirm that I've made a best effort attempt to update all relevant documentation.
• I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jlizen]

I haven't looked closely but it looks like this impl would require adding generics for the runtime API client and other breaking changes? Customers are unlikely to name them but we probably still can't do break that API... Probably we need to cut over to a new type and deprecate the old? What are you thinking?

[FullyTyped]

Adding a non-constrained generic shouldn't be a problem, and it is pretty beneficial in this scenario.

I guess the alternative is injecting a client that communicates over channels.

I am not sure. Maybe there's a different way to test this that I am just missing.

[jlizen]

I guess the alternative is injecting a client that communicates over channels.

Big ++ to this - some sort of test-util-feature-gated utility that allows overriding the client with an arbitrary trait implementation, seems great.

Adding a non-constrained generic shouldn't be a problem

Not a problem, but it is semver breaking, in case anybody names the type. (They are unlikely to, but still). Along similar lines, we are adding a new variant to RuntimeApiClientFuture, which is not tagged as #[non_exhaustive], which is also breaking.

I don't think it's a big deal, these are unlikely to be used by end user code, but we probably should play by the rules and add new names for these and deprecate the old? Anyway if we cut over all of our other crates relying on these types, end user churn would be minimal.