Add streaming timing metrics to generic stream wrappers

[Nik-Reddy]

Closes #8

What this does

Adds three streaming timing measurements to the shared utils layer:

1. gen_ai.client.operation.time_to_first_chunk histogram
2. gen_ai.response.time_to_first_chunk span attribute
3. gen_ai.client.operation.time_per_output_chunk histogram (one data point per inter-chunk gap)

All timing logic lives in the stream wrapper base classes (SyncStreamWrapper/AsyncStreamWrapper in util/opentelemetry-util-genai). The OpenAI chat wrappers just pass through the invocation start time and copy measured values back, keeping provider-specific code minimal.

How timing works

• TTFC: measured from invocation start (when the HTTP request was issued) to when the first chunk arrives
• time_per_output_chunk: measures the blocking read duration for each chunk after the first, so user processing time between pulls doesn't inflate the metric
• Uses timeit.default_timer() around the blocking next()/anext() call

Scope

This wires up timing for OpenAI chat completions streams (which use the shared ABC). Anthropic and the Responses API have their own stream wrappers that don't extend the ABC, so they will need separate follow-up work.

Testing

• 5 unit tests for the timing logic in stream.py (sync, async, single chunk, error cases)
• 2 integration tests verifying histogram recording in metrics.py
• All existing tests still pass

[Copilot]

Pull request overview

Adds shared streaming timing support in the GenAI utility layer and wires OpenAI v2 chat stream wrappers to propagate those timings into inference telemetry.

Changes:

• Adds TTFC and per-output-chunk timing capture to sync/async stream wrapper base classes.
• Records new streaming timing histograms and the TTFC span attribute from InferenceInvocation.
• Updates OpenAI v2 chat stream wrappers, changelogs, and utility tests for the new timing behavior.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
util/opentelemetry-util-genai/src/opentelemetry/util/genai/stream.py	Measures TTFC and per-chunk read durations in shared sync/async stream wrappers.
util/opentelemetry-util-genai/src/opentelemetry/util/genai/metrics.py	Records streaming timing histograms from invocation timing fields.
util/opentelemetry-util-genai/src/opentelemetry/util/genai/instruments.py	Defines histogram creation helpers for streaming timing metrics.
util/opentelemetry-util-genai/src/opentelemetry/util/genai/_inference_invocation.py	Adds timing fields and emits TTFC as an inference span attribute.
instrumentation/opentelemetry-instrumentation-openai-v2/src/opentelemetry/instrumentation/openai_v2/chat_wrappers.py	Passes invocation start time into stream wrappers and copies measured timings back.
util/opentelemetry-util-genai/tests/test_stream.py	Adds sync/async stream wrapper timing tests.
util/opentelemetry-util-genai/tests/test_handler_metrics.py	Adds metric recorder tests for streaming timing histograms.
util/opentelemetry-util-genai/CHANGELOG.md	Documents utility streaming timing support.
instrumentation/opentelemetry-instrumentation-openai-v2/CHANGELOG.md	Documents OpenAI v2 chat streaming timing metrics.

Comments suppressed due to low confidence (1)

util/opentelemetry-util-genai/src/opentelemetry/util/genai/stream.py:217

• The async wrapper has the same unbounded accumulation issue: _self_chunk_gaps stores one entry per output chunk until the stream finalizes. For large or long-lived streams this can grow without bound; prefer recording each gap immediately or passing timings through a bounded recorder.

        self._self_chunk_gaps: list[float] = []

[Nik-Reddy]

@lmolkova This implements the three items you mentioned in #8:

• gen_ai.response.time_to_first_chunk span attribute
• gen_ai.client.operation.time_to_first_chunk histogram
• gen_ai.client.operation.time_per_output_chunk histogram (one record per inter-chunk gap)

For chunk gaps I'm measuring blocking read time rather than wall clock between returns, so user-side processing doesn't inflate it. Let me know if that's not what you had in mind.

Anthropic/Responses API don't use the ABC yet so they'll need follow-up work in a separate PR.

[MikeGoldsmith]

Looks mostly okay, I've left a few of comments we should resolve before accepting.