Refactor duplication between Traces and Logs

[kaylareopelle]

Once the Logs SDK and Logs API implementations are stable and ready to be merged into the main API and SDK gems, let's refactor the code for the Trace SDK and API to reduce duplication between the signals.

[fbogsany]

I'm not sure what we've covered in the Logs SDK and API implementations. Note that the Events API is still "experimental", so we don't want to merge that into the main API gem yet. The rest of the Logs API and SDK specs seem to be stable, so we can start to merge them into the main API and SDK gems.

[kaylareopelle]

@fbogsany - The Logs API implementation on main meets the spec. We could release an alpha version on RubyGems, though I’m unsure how valuable that would be without the SDK.

For the Logs SDK, the end-to-end code has been written, but not reviewed. #1517 blocks the other functionality from review. I want to keep the scope of the Logs SDK PRs small and focus on one spec concept at a time. There’s also an OTLP logs exporter and basic instrumentation for Ruby’s logger library awaiting review once the SDK code review is complete.

[kaylareopelle]

Update 2023-12-12: During today’s SIG, @robbkidd brought up the rule that you should abstract after you have 3+ of something. With that in mind, this work might begin as part of the Events implementation.

[github-actions[bot]]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.