Support for Serialization and De-serialization of Metrics and Logs using Spring Data

Is your feature request related to a problem? Please describe.

The current metric (potentially also log) types of OTel Java Instrumentation do not support serialization / de-serialization and persistence using Spring Data. The persistence fails due to the classes of OTel Java Instrumentation not having been compiled with the -parameters compiler flag and partially because they don't always provide a default constructor.

Persistence of metrics and logs becomes relevant for scenarios where the metrics and logs must not be lost, i.e. some delivery guarantees need to be given. Examples of such scenarios are logs used for audit logging, or metrics used in commercial metering environments.

Please also see this discussion thread I had opened some time ago: https://github.com/open-telemetry/opentelemetry-java/discussions/7554

Describe the solution you'd like

The OpenTelemetry classes for metrics and logs, potentially also trace spans should be serializable / de-serializable and support persistence via Spring Data. This will allow application developers wanting to use OpenTelemetry in scenarios where delivery guarantees are required (e.g. audit logging, metering) to temporarily persist OTel data and export it later, in case of temporary error situations that make sending the data impossible.

Describe alternatives you've considered
Serializing classes via frameworks like Jackson to XML or JSON and persisting that instead. Still need to try out, if this would be a valid option.

Additional context
More details, also on what would have to change in the OTel Java instrumentation to support this can be found here.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

Start with the linked discussion at github.com/open-telemetry/opentelemetry-java/discussions/7554 and review the metric and log classes involved in the reported Spring Data failures. Determine the serialization, deserialization, constructor, and compiler requirements before defining scope. Done should include a decided approach that supports the relevant OpenTelemetry data types and persistence use cases.