feat: stabilization of opentelemetry-etw-logs

[psandana]

Fixes #
Design discussion issue (if applicable) #

Changes

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Attention: Patch coverage is 97.31183% with 10 lines in your changes missing coverage. Please review.

Please upload report for BASE (main@7a2634f). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
opentelemetry-etw-logs/src/logs/processor.rs	97.5%	4 Missing ⚠️
...pentelemetry-etw-logs/src/logs/exporter/options.rs	98.2%	3 Missing ⚠️
stress/src/etw_logs.rs	0.0%	3 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff           @@
##             main    #247   +/-   ##
======================================
  Coverage        ?   52.5%           
======================================
  Files           ?      64           
  Lines           ?    8737           
  Branches        ?       0           
======================================
  Hits            ?    4593           
  Misses          ?    4144           
  Partials        ?       0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[cijothomas]

why test log here specifically? Exporters should have no connection to the logging library anyway right?

[psandana]

I agree, and for that we should use the LogRecord interface directly. But as we decided to not do so, and use tracing, I also feel we should explicitly test the integration of log crate for parity.

[cijothomas]

please make those changes in separate PR to keep the scope in control. This is already touching too many aspects in one PR.

[cijothomas]

@lalitb @utpilla
Would love to get more feedback on this approach.
One downside with this approach is that, users will most likely need to write LogRecordProcessor to customize Name,Target as their defaults may not work well. (i.e the default name, target provided by tracing is not likely useful)

Other option is to expose a callback for end-users, in the exporter.
get_etw_event_name(&log_record) -> &str
This has the upside that users can return the name without having to replace the original name (and target), so PartB.Log.name will always contain the original EventName, and users can influence PartA-name (and Table names in backend). This does have a risk of letting arbitrary user code run in the hot path. Given the alternative is to write LogRecordProcessor, which is also arbitrary user-code, we could reconsider (@psandana yes, I known I was not very supportive of providing arbitrary callbacks, but considering the full picture, I can change my position) this approach.