fix: SimpleProcessor for Logs simplified

[cijothomas]

SimpleLogProcessor has no technical reason to Mutex wrap the exporter, as it does not need mutable ref to exporter. However, as per spec, only one Export() can be active at a time. This PR removes the Mutex wrapping of exporter, and uses a separate bool to sequence the export() calls.
This simplifies other methods, which no longer has to lock the exporter.

There is minor perf gains, but that should be immaterial as SimpleProcessor for only for test/learn purposes.

[codecov]

Codecov Report

Attention: Patch coverage is 95.45455% with 1 line in your changes missing coverage. Please review.

Project coverage is 80.4%. Comparing base (31b494b) to head (0ec2536).

Files with missing lines	Patch %	Lines
opentelemetry-sdk/src/logs/simple_log_processor.rs	94.7%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #2825     +/-   ##
=======================================
- Coverage   80.4%   80.4%   -0.1%     
=======================================
  Files        124     124             
  Lines      23390   23371     -19     
=======================================
- Hits       18828   18811     -17     
+ Misses      4562    4560      -2     

☔ 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.

[utpilla]

This code is not complicated. It's simple enough.

I don't find the Mutex<()> approach making things simpler. In fact, from a readability/maintenance standpoint, the existing export code is much better than the one introduced in this PR. If you're using a Mutex to guard access to some resource, then it's best to wrap it with Mutex instead of having to manually ensure that we acquire a Mutex.

I don't see the need to go against the Rust way of doing things in this case. The current SimpleProcessor neither has the perf requirements nor the complexity to switch to manual dependency on acquiring Mutex.

[cijothomas]

I don't disagree at all!
It felt quite awkward to Mutex lock to do EventEnabled(), though it did not require mutability!
Not worried about performance at all here, just does not feel right to do that.

Regd. Rust idiomatic way to prevent multiple export at the same time - I think it'd be better to model export() as requiring mutable self, but we know that will limit us from achieving higher perf when we need it!

If all agree this PR is wrong direction, I can abandon it. (Its harmless with/without this PR, as simple processor is just a learning/test purpose component only)