integration-tests: cover more signals

[wpessers]

Context
Currently, the integration tests introduced in #2322 only validate the traces signal. We should extend the integration tests to also validate metrics and logs.

• metrics validation added
• logs validation added

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[myselfkunal]

Took a look at the current test and the handlers across all four languages (python, nodejs, ruby, java). Right now every handler does the same thing: one sts.get_caller_identity() call (or the language equivalent), which produces exactly one auto-instrumented trace span. None of them currently emit anything that would show up as a metric or a log record, so covering those signals isn't just adding new assertions, it means first getting a handler to actually produce that telemetry.

Rather than trying to cover both signals across all four languages in one PR, I'd like to start narrower: add metrics coverage for the Python handler first, then follow up with logs and the other languages as separate PRs. Keeps each change small and easy to review instead of one big diff touching every handler.

For Python specifically, I still need to check whether the boto3 auto-instrumentation already emits anything on its own (some AWS SDK instrumentation packages emit request duration metrics by default) or if I need to add something deliberately to get a meaningful assertion.

Let me know if that scope sounds reasonable. Happy to start on it once confirmed.

[tylerbenson]

I'm always happy for additional testing. As for the direction I'll let @wpessers weigh in on the specific approach. Seems ok to me though.

[myselfkunal]

Sounds good, thanks @tylerbenson ! @wpessers , let me know if the scoped approach (Python metrics first, then logs + other languages as follow-ups) works for you, and I'll get started.