Add force_flush to LogExporter

[ThomsonTan]

Fixes #2261
Design discussion issue (if applicable) #

Changes

Added the force_flush interface to LogExporter and call it in the LogProcessor, right after flushing the export queue.

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 96.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 79.4%. Comparing base (6d1a765) to head (71d4b40).

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

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2276   +/-   ##
=====================================
  Coverage   79.4%   79.4%           
=====================================
  Files        123     123           
  Lines      21479   21501   +22     
=====================================
+ Hits       17068   17089   +21     
- Misses      4411    4412    +1     

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

[lalitb]

Can we also add a unit-test for batch processor, with mock-exporter, to validate that the exporter's force flush get's called.

[lalitb]

We may need to add both sync and async versions for provider / processors and exporter for shutdown() and force_flush(), and so different pipelines based on what is invoked. I am looking into those aspects, but this PR change would be still required. @cijothomas @utpilla @TommyCpp if anyone has concern here.

[utpilla]

Let's update the comments here to reflect the actual trait method definition instead of putting the spec guidelines for this method.

We could put something like:

/// This method will block the current thread until all pending log records are exported. If the export was not
/// successful, an error is returned.

[utpilla]

I think we should not have a default implementation for this method. Otherwise, we could run into a situation where an exporter user goes through the documentation and calls force_flush with certain expectations that haven't been agreed upon by the exporter author.

It looks like we have a default implementation for a few other methods as well such as shutdown and set_resource. We should revisit them based on what we decide.

[cijothomas]

Otherwise, we could run into a situation where an exporter user goes through the documentation and calls force_flush with certain expectations that haven't been agreed upon by the exporter author.

If the exporter author does not provide an implementation for flush, then they can document that right? Or the doc for Provider can be updated to merely state that it'll invoke flush on the processor, and the same for processor can state they will invoke the flush for exporter.

Default implementation seems reasonable to me, as not every exporter need to do something for flush.

[utpilla]

Do we need this? export_with_timeout already calls exporter.export which is what is expected from force_flush.

[lalitb]

@ThomsonTan can we address the comments, and resolve the conflicts, to be eventually merged.