Implement partial success logging in OTLP exporters

[michaelsafyan]

Log partial success based on $OTEL_LOG_LEVEL

When $OTEL_LOG_LEVEL is verbose or debug, partially succeeding responses will be logged.

Fixes #4803

Type of change

• New feature (non-breaking change which adds functionality)
• [?] This change requires a documentation update

How Has This Been Tested?

Added new unit tests covering the relevant cases.

Does This PR Require a Contrib Repo Change?

• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• [] Documentation has been updated - unsure what to update

[DylanRussell]

Why put this log behind an env var ? Why not just always log when the field is set -- I'm assuming it's only set when there was a partial success -- it doesn't sound too noisy to me.

[michaelsafyan]

Why put this log behind an env var ? Why not just always log when the field is set -- I'm assuming it's only set when there was a partial success -- it doesn't sound too noisy to me.

I'm uncertain as to the level of noisiness, and so I wanted to minimize disruption to existing users. I could imagine it being somewhat annoying if every batch included one persistently malformed span that just ended up creating log spam.

A more sophisticated approach might be to opt-in to recording every partial success, while elevating the verbosity and logging the partial success unconditionally if every record was a failure (if num_rejected_{type} matches the number of items in the batch). But I wanted to keep things relatively simple.

[DylanRussell]

We already have the DuplicateFilter on this logger, maybe we should tweak that to de-dupe based on line no and module instead of message which can be unique so that it filters stuff out better.

I think it's a bit weird to put just 1 log message behind this env var