feat(sdk-logs)!: invoke exporter forceFlush without first awaiting export

[pichlermarc]

Which problem is this PR solving?

This PR tackles two things that are related:

From the Specification:

In particular, if any LogRecordProcessor has any associated exporter, it SHOULD try to call the exporter's Export with all LogRecords for which this was not already done and then invoke ForceFlush on it. The built-in LogRecordProcessors MUST do so. If a timeout is specified (see below), the LogRecordProcessor MUST prioritize honoring the timeout over finishing all calls. It MAY skip or abort some or all Export or ForceFlush calls it has made to achieve this goal.

Makes the BatchLogRecordProcessor#forceFlush() spec compliant by calling LogRecordExporter#forceFlush() for the export that is currently scheduled, as well as all following exports within the flush operation. Calling forceFlush() means that we tell the exporter to speed up the export, however, we need to make sure we do not await the export before calling forceFlush() as there's little point to that - this is what we're currently doing in the Trace SDK and Metrics SDK. See #6340 for the big picture on how I'm planning to change these.

It also adds LogRecordExporter#forceFlush() so that it can be called in the first place (ref #6352)
This was already implemented in the OTLP exporters, since they share the same base exporter with Traces and Metrics, however third-party exporters may not implement this - that's why I marked this change as a breaking change.

The reason why I made this operation requires is this specification:

A LogRecordExporter MUST support the following functions:
[...]
ForceFlush

Additonal info: the motivation for this change is spec compliance, but also to eventually allow cancelling of retries in the OTLP exporter, speeding up shutdown when the OTLP endpoint is not available (ref open-telemetry/opentelemetry-js-contrib#3349).

Fixes #6352

Short description of the changes

Type of change

Please delete options that are not relevant.

• Bug fix (not calling forceFlush is not spec compliant)
• New feature (forceFlush is new on the exporter interface)
• Breaking change (forceFlush being new means that existing third-party exporters have to implement it)

How Has This Been Tested?

• Unit tests
• Existing Tests
  • I had to change some tests as they heavily relied on internal timing of the processor that was not fully guaranteed.

[codecov]

Codecov Report

❌ Patch coverage is 89.56522% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.73%. Comparing base (d583a22) to head (ac1c6ac).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...sdk-logs/src/export/BatchLogRecordProcessorBase.ts	90.09%	11 Missing ⚠️
...es/sdk-logs/src/export/ConsoleLogRecordExporter.ts	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6356      +/-   ##
==========================================
- Coverage   95.75%   95.73%   -0.03%     
==========================================
  Files         371      371              
  Lines       12514    12571      +57     
  Branches     2962     2971       +9     
==========================================
+ Hits        11983    12035      +52     
- Misses        531      536       +5     

Files with missing lines	Coverage Δ
...s/sdk-logs/src/export/InMemoryLogRecordExporter.ts	100.00% <100.00%> (ø)
...es/sdk-logs/src/export/ConsoleLogRecordExporter.ts	91.66% <50.00%> (+8.33%)	⬆️
...sdk-logs/src/export/BatchLogRecordProcessorBase.ts	91.15% <90.09%> (-1.07%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pichlermarc]

@trentm - thanks for the review! Issues should be addressed now and the PR is ready for another round :)

[trentm]

LGTM, modulo the changelog conflict.
Sorry that I dropped the ball on re-reviewing this for so long.

[trentm]

Idle perf thought (not really related to this PR): The common case will be all these logRecord.resource things being the same resource object. I wonder if using a Set to reduce the number of resource objects to Promise.all() on would be faster.

[pichlermarc]

Good point! Created #6568 to follow up on this :)