[export] Temporary workaround to race condition

Right now there's no ordering between the set context from the SetCall callback chain in server.cc, and the read context a few lines down from the new if statement inserted here -- that is if a call is cancelled whilst the server is initializing the context we see a tsan race.

Until #36598 this was a non-issue however because we were entirely discarding the cancellation edge. Now that we've gotten that back again, this race is appearing.

I'd like us to fix this properly, but to do so probably needs some deeper work on what contexts are and how they're initialized -- and that's not for this week (but maybe this month).

----
DO NOT SUBMIT. This PR is for testing purposes only. [cl/635328547](http://cl/635328547)

PiperOrigin-RevId: 635328547

src/core/ext/filters/backend_metrics/backend_metric_filter.cc

@@ -129,6 +129,7 @@ BackendMetricFilter::Create(const ChannelArgs&, ChannelFilter::Args) {
 }
 
 void BackendMetricFilter::Call::OnServerTrailingMetadata(ServerMetadata& md) {
+  if (md.get(GrpcCallWasCancelled()).value_or(false)) return;
   auto* ctx = &GetContext<
       grpc_call_context_element>()[GRPC_CONTEXT_BACKEND_METRIC_PROVIDER];
   if (ctx == nullptr) {