Remove global error handler in favor of internal logs

[lalitb]

• Internal logs support is now available (Improve internal opentelemetry logging #2128), and it would make sense to use it for internal errors.
• This allows the removal of the global error handler.
• Current downside: it won’t be possible to register a custom handler for errors at this time. However, plan is to add support for registering custom handlers for internal logs.
• If "internal-logs" is enabled, tracing error macro would be used for handling error, else the eprintln would be used.

[mlowicki]

Saw issue with using eprintln as the default error handler as it causing flood of writes to STDERR like OpenTelemetry trace error occurred. cannot send message to batch processor as the channel is full. Would it make sense to have something throttled by default or at least an visible option to enable in order to avoid hammering with tons of messages.

[lalitb]

Saw issue with using eprintln as the default error handler as it causing flood of writes to STDERR like OpenTelemetry trace error occurred. cannot send message to batch processor as the channel is full. Would it make sense to have something throttled by default or at least an visible option to enable in order to avoid hammering with tons of messages.

That's a valid concern. I'm not entirely sure how we could achieve this directly, but will look it as potential improvement for future. For now, don't see this as a blocker, since the issue can be mitigated externally using a script to throttle the stderr output.

[cijothomas]

For this specific one, I don't think there should be a log entry for channel full for each message. It is best exposed as an internal metric only. If a log is needed, it can be done at the shutdown time "N items were dropped due to buffer full"/similar.