fix: handle HTTP 413 by splitting and retrying in OTLP HTTP exporters

[Krishnachaitanyakc]

Summary

When a backend returns HTTP 413 (Payload Too Large), the OTLP HTTP trace and log exporters now split the batch in half and recursively retry each half, preventing silent data loss when batch sizes exceed backend limits.

Fixes #4533

Changes

• Added _is_payload_too_large() helper in _common/__init__.py
• Refactored export() to delegate to _export_batch() in both trace and log exporters
• _export_batch() handles 413 responses with binary splitting:
  • Base case: single-item batch returns FAILURE (item is genuinely too large)
  • Deadline guard: if deadline expired, returns FAILURE without recursing
  • Short-circuit: if first half fails, second half is not attempted
  • Recursive split: halves the batch and exports each half independently

Notes

• The metric exporter already has proactive batch splitting via max_export_batch_size and _split_metrics_data(). Reactive 413 handling for metrics is deferred to a follow-up since metric data has a nested protobuf structure that requires different splitting logic.
• The gRPC exporter uses a different status code system (RESOURCE_EXHAUSTED) and would need separate handling in a future PR.

Test plan

• 5 new span exporter tests: split success, single-item failure, recursive splitting, partial failure short-circuit, deadline expiry
• 5 new log exporter tests: same scenarios
• All existing tests pass (no regressions)
• ruff linter passes