Add support for empty values in Logs Data Model

[pellared]

Fixes #3835

Changes

• Define empty value as an acceptable type for any

I think that adding support for additional type is not a breaking change. I also think that users may also want to preserve the empty values that are in structured data (e.g. record body and attributes) that they emit in their applications.

E.g. slog a structured logging package which is part of Go standard library accepts nil (null, empty value) as a valid attribute value. The Bridge API should do its best to carry over as much logging data as possible until it is can be passed via OTLP . See: https://go.dev/play/p/KN5Wea6h_f-

[pellared]

@jack-berg @tigrannajaryan I updated the PR. PTAL

[tigrannajaryan]

I believe this should be treated as a backward compatible change because:

1. From API callers perspective it widens the API, so no existing code should break.
2. From data consumers perspective nothing changes since OTLP already explicitly allows empty values, so consumers must be already prepared for this.

Does anyone think this is an incorrect interpretation of our compatibility rules?

[trask]

makes sense to me because it's needed for faithfully bridging existing logging systems