[Prototype] spaneventbridge: add processor that bridges log-based events back onto the current span as span events

[pellared]

Prototype for https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4430-span-event-api-deprecation-plan.md#sending-log-based-exceptions-and-events-as-span-events

Based on https://github.com/open-telemetry/opentelemetry-java-contrib/blob/80adbe1cf8de647afa32c68f921aef2bbd4dfd71/processors/src/main/java/io/opentelemetry/contrib/eventbridge/EventToSpanEventBridge.java

@open-telemetry/go-maintainers, asking for an overall review of the prototype. I do not want to merge this at this point of time.

[pellared]

Note that this won't be needed when Logs API is going to use attribute

[codecov]

Codecov Report

❌ Patch coverage is 54.31034% with 53 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.2%. Comparing base (6b85d9a) to head (4d23156).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
processors/spaneventbridge/log_processor.go	54.3%	49 Missing and 4 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #8760     +/-   ##
=======================================
- Coverage   83.4%   83.2%   -0.3%     
=======================================
  Files        192     193      +1     
  Lines      15598   15722    +124     
=======================================
+ Hits       13024   13088     +64     
- Misses      2127    2185     +58     
- Partials     447     449      +2     

Files with missing lines	Coverage Δ
processors/spaneventbridge/log_processor.go	54.3% <54.3%> (ø)

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dashpole]

I like this design a lot. I would consider spaneventbridge as a name.

[flc1125]

I think it’s quite good overall. One additional small suggestion:

Since log reporting needs to be tracked based on the ctx returned by span, it would be nice if this could be explicitly communicated to users. Because most users may use a ctx that does not contain span information, which could lead them to think the report was sent when it actually wasn’t.

One possible approach: use Warn output.

[pellared]

Since log reporting needs to be tracked based on the ctx returned by span, it would be nice if this could be explicitly communicated to users. Because most users may use a ctx that does not contain span information, which could lead them to think the report was sent when it actually wasn’t.

One possible approach: use Warn output.

We may want to improve the https://pkg.go.dev/go.opentelemetry.io/otel/log#Logger docs. Note that some log records may be emitted outside of any span.