Enforce OTLP request size limits

[ADITYA-CODE-SOURCE]

Fixes #8444.

Why

• opentelemetry-proto#782 now recommends that OTLP exporters enforce configurable outbound request/message size limits.
• OpenTelemetry Java already limits response body reads, but OTLP exporters did not enforce outbound request/message limits.

What

• add configurable request/message size limits to OTLP HTTP and gRPC exporter builders with a default of 64 MiB
• enforce the limit in the shared OTLP HTTP and gRPC exporter layers before dispatching requests
• cover both known-size binary payloads and unknown-size payloads (for example OTLP HTTP JSON) by measuring when needed
• add focused tests for over-limit failure behavior and builder configuration plumbing
• update docs/apidiffs/current_vs_latest/opentelemetry-exporter-otlp.txt for the new public builder methods

Testing

I was not able to complete local Gradle verification on this Windows machine because Gradle / the Kotlin compiler daemon repeatedly failed to start due to paging-file / metaspace limits before compilation finished. The changes are pushed for CI verification.

[otelbot]

⚠️ API changes detected — additional maintainer review required

@jack-berg @jkwatson

This PR modifies the public API surface area of the following module(s):

• opentelemetry-exporter-otlp

Please review the changes in docs/apidiffs/current_vs_latest/ carefully before approving.

[ADITYA-CODE-SOURCE]

@jkwatson Thanks — I pushed a follow-up that fixes the NullAway compile failure in the OTLP internal exporters and applies the naming nits to use constants and public API parameter names.

[jack-berg]

A few small comments, but looks pretty good! Thanks for working on this!

[jack-berg]

Under what conditions do we pass through this?

My read of the code shows that only Marshaler.toJsonMessageWriter produces a MessageWriter.getContentLength which can return a value <= 0.

I don't know that we can cheaply compute the / enforce the body size for OTLP/json. One more reason not to use it. Officially, we don't support it today. See #5833

[ADITYA-CODE-SOURCE]

Fixed the remaining Spotless failure in OtlpGrpcProfilesExporterBuilder and pushed it in 17cec6745. The previous build failures were all caused by that formatting issue; rerunning CI now.

[jack-berg]

Looks like there are still some build failures from static analysis.

Couple more nits to fix along with the build, but looks good to me

[jack-berg]

Why two methods?

[jack-berg]

#nit: can initialize CompletableResultCode as failed with the exception:

Suggested change

	CompletableResultCode result = new CompletableResultCode();
	result.failExceptionally(FailedExportException.grpcFailedExceptionally(exception));
	return result;
	return CompletableResultCode.ofExceptionalFailure(FailedExportException.grpcFailedExceptionally(exception));