opentelemetry-instrumentation-botocore: capture Bedrock prompt cache token usage

[vinigrazzioli-96]

Description

Amazon Bedrock's Converse / ConverseStream APIs return cacheReadInputTokens
and cacheWriteInputTokens in the response usage when prompt caching is
used. The botocore Bedrock instrumentation currently reads only inputTokens
/ outputTokens, so the cache token counts are dropped.

This PR maps them to the OTel GenAI semantic-convention attributes (already
defined in opentelemetry-semantic-conventions):

• cacheReadInputTokens → gen_ai.usage.cache_read.input_tokens
  Changes:
• bedrock.py (_converse_on_success): set the cache token span attributes
  for Converse / ConverseStream / InvokeModelWithResponseStream.
• bedrock_utils.py (ConverseStreamWrapper): accumulate the cache token
  counts from the streaming metadata event into the response usage.

Out of scope (possible follow-up): the non-streaming InvokeModel Claude
path uses the native Anthropic usage format (cache_read_input_tokens /
cache_creation_input_tokens, snake_case) and would need a separate change.

Fixes #4614

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Added test_converse_stream_accumulates_cache_tokens, a unit test that
  feeds a metadata event carrying cache token usage to ConverseStreamWrapper
  and asserts the counts are accumulated.
• tox -e py311-test-instrumentation-botocore-1-wrapt1 — 134 passed
• tox -e lint-instrumentation-botocore — 10.00/10

Checklist

• Followed the style guidelines of this project
• Changelog has been updated
• Unit tests have been added
• Documentation has been updated (N/A — internal attribute change)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: vinigrazzioli-96 / name: Vinicius Moscon (55d8c17)

[xrmx]

It would be nice to also assert the attributes on a test with a recording instead, if this isn't something added recently you may already have it in the recordings.

[vinigrazzioli-96]

Thanks for the review @xrmx! I looked into this — the cache token fields (cacheReadInputTokens / cacheWriteInputTokens) are only part of the bedrock-runtime service model on more recent boto3 (≥ 1.39.5). The current test factors all pin older versions (1.29.4 in -2, 1.35.16 in -3, 1.35.56 in -1), which strip these fields from the response before the instrumentor sees them — so a VCR cassette alone wouldn't help. That's why I went with the unit test on ConverseStreamWrapper to validate the streaming-metadata accumulation.

If you'd prefer a VCR-based test, I can bump boto3 in one of the factors (e.g. -3) to ≥ 1.39.5 and record a cassette with prompt caching enabled. Happy to do either — let me know how you'd like to proceed.