reduce number of scope activations in gRPC client instrumentation

[richardstartin]

What Does This Do

#4646 and #4680 changed the way context propagation worked in the gRPC instrumentation: rather than context being captured by SerializingExecutor.schedule (which simply executes the SerializingExecutor itself as a Runnable)
and activated by SerializingExecutor.run (which drains a queue of Runnable tasks and runs each one) the context was now captured by each task submitted to SerializingExecutor.execute and activated when each task would run. This prevents the context active when SerializingExecutor.schedule was called being active when each task runs. However, a single SerializingExecutor only ever executes tasks for the same request, so allowing SerializingExecutor.run to activate the scope once drastically reduces the number of scope activations (they are all the same scopes), thus reducing tracing overhead. This change essentially reverts #4646 and #4680 and lets SerializingExecutor.run capture and activate the same scope for all the tasks it executes.

Motivation

Reduce overhead

Additional Notes

[pr-commenter]

Benchmarks

Parameters

	Baseline	Candidate
commit	1.17.0-SNAPSHOT~103ef9223f	1.17.0-SNAPSHOT~c91cb61f84
config	baseline	candidate

See matching parameters

	Baseline	Candidate
module	Agent	Agent
parent	None	None

Summary

Found 0 performance improvements and 0 performance regressions! Performance is the same for 22 cases.

[bantonsson]

I assume that you're referring to #4646 and not #4676