Use HTTP error bodies in HttpExporter warnings

[ADITYA-CODE-SOURCE]

Fixes #7704.

Why

• HttpExporter currently tries to parse every non-success HTTP response body as a serialized gRPC status.
• When a custom server returns a JSON error body instead, export failure is reported correctly, but the warning text degrades to Unable to parse response body, which is noisy and hides the actual server response.

What

• keep gRPC status parsing for responses that contain a serialized gRPC status body
• fall back to logging the UTF-8 response body text when parsing fails
• fall back to the HTTP status message when the body is empty
• add a targeted test covering a JSON error response body

Testing

• ./gradlew --no-daemon --max-workers=1 -Dorg.gradle.jvmargs="-Xmx768m -XX:MaxMetaspaceSize=256m" :exporters:common:test --tests io.opentelemetry.exporter.internal.http.HttpExporterTest
• ./gradlew --no-daemon --max-workers=1 -Dorg.gradle.jvmargs="-Xmx512m -XX:MaxMetaspaceSize=192m" :exporters:common:spotlessCheck

[psx95]

This PR improves the default parsing experience of gRPC errors in HttpExporters by converting the raw bytes to a UTF-8 string as a fallback.

Looking at the original issue #7704 - the original ask was for a way to suppress the noisy logs - this PR makes the logs helpful, but does not suppress it - which IMO is ok (IIUC, a decision was not taken on it), but I'll defer to the maintainers here.

[psx95]

QQ: Why was this number chosen?

[ADITYA-CODE-SOURCE]

Chose 1024 as a conservative cap so failed exports can still show the server response without letting a large payload flood the warning log. Happy to adjust the bound if you would prefer a different limit.

[psx95]

nit: could add a better message indicating this is a length = 0 case.

Something like "Response body has 0 length, HTTP status message: "

[ADITYA-CODE-SOURCE]

Addressed in the latest version: zero-length bodies now produce a specific message instead of the generic fallback.

[psx95]

nit: Minor improvement:

 int lengthToRead = Math.min(responseBody.length, MAX_RESPONSE_BODY_LOG_LENGTH);
 String responseBodyText = new String(responseBody, 0, lengthToRead, StandardCharsets.UTF_8).trim();

[ADITYA-CODE-SOURCE]

Addressed in the latest version: decoding is now bounded to the configured max length before converting to UTF-8.

[ADITYA-CODE-SOURCE]

@psx95 Addressed the nits — bounded decoding, zero-length message, 1024 comment, and rebased onto latest main. I relied on CI for post-rebase verification since Gradle won't start locally due to paging-file limits.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.03%. Comparing base (2f1d950) to head (29c06ac).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8428      +/-   ##
============================================
+ Coverage     90.96%   91.03%   +0.06%     
- Complexity     7809     7824      +15     
============================================
  Files           892      893       +1     
  Lines         23702    23729      +27     
  Branches       2361     2366       +5     
============================================
+ Hits          21561    21602      +41     
+ Misses         1420     1408      -12     
+ Partials        721      719       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ADITYA-CODE-SOURCE / name: ADITYA-CODE-SOURCE (29c06ac, 323e2b4, 47159e2, be4b328, fff6013)

[ADITYA-CODE-SOURCE]

Quick clarification on scope: this PR does not suppress the warning itself. It keeps the existing warning behavior, but makes the warning actionable for non-gRPC HTTP error responses by surfacing the returned body text when gRPC status parsing fails. For empty or missing bodies it still falls back to the HTTP status message.\n\nI also pushed a small cleanup commit to reuse for the null-body test case raised in review.

[opentelemetry-pr-dashboard]

This PR has review comments. Review suggestions, whether from maintainers or automated reviewers, aren't always correct or required. Please evaluate each comment on its merits, then make sure each thread has a clear outcome.

For example, link to the commit if you applied a suggestion, explain why it wasn't applied, or ask a follow-up question.

Automation flags a PR for human review once every review thread has a reply or is marked as resolved.

Status across open PRs is visible on the pull request dashboard.

[opentelemetry-pr-dashboard]

This PR has review comments. Review suggestions, whether from maintainers or automated reviewers, aren't always correct or required. Please evaluate each comment on its merits, then make sure each thread has a clear outcome.

For example, link to the commit if you applied a suggestion, explain why it wasn't applied, or ask a follow-up question.

Automation flags a PR for human review once every review thread has a reply or is marked as resolved.

Status across open PRs is visible on the pull request dashboard.

[psx95]

@ADITYA-CODE-SOURCE could you fix the failing CI on this PR to ensure that the new changes are good?

Quick clarification on scope: this PR does not suppress the warning itself. It keeps the existing warning behavior, but makes the warning actionable for non-gRPC HTTP error responses by surfacing the returned body text when gRPC status parsing fails. For empty or missing bodies it still falls back to the HTTP status message.\n\nI also pushed a small cleanup commit to reuse for the null-body test case raised in review.

Also, could you update the description to remove "Fixes" from before the issue reference - otherwise merging this would close the issue and this comment clearly indicates that the PR does not address the mentioned issue.