Measure time outbound ops are sitting in queue due to active batch

[vladsud]

With move toward batching being by default at JS turn granularity, we will change how long it takes from the time someone make a local change (DDS) to side-effects (op) to be sent to socket. If application spends a lot of time doing very expensive operations in response to user actions, this time might be long, and it will impact end-to-end op latency metrics we track (see first item below).

Related issues:

• fluid:telemetry:OpPerf:OpRoundtripTime errors are hit in prod #7406
• Track time ops are sitting in inbound queue before they are processed #8912
• Track op roundtrip time without any impact from runtime side #8911

Ideally, we track all these metrics on a single op, such that we can easily do math on these metrics.

@andre4i - FYI.

[vladsud]

Please see the comment I've just added in #8912 re stages.
This bug tracks tracking time between stages 1-2.
Please note that if we fix above mentioned bug, we could calculate that time (from all other metrics).
But I'd record it explicitly, as it will help us see if data is consistent (and thus makes sense), or vice versa (i.e., it will be easier to see bugs if any)