otel: add test for batch splitting with the elasticsearchexporter

[mauri870]

What does this PR do?

Adds a test that the elasticsearchexporter does batch splitting properly on large batches comming from a beats receiver.

Why is it important?

This guarantees that the scenario covered in elastic/beats#41911 does not happen again.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Related issues

• For https://github.com/elastic/ingest-dev/issues/3677

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[mergify]

This pull request does not have a backport label. Could you fix it @mauri870? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-v8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[jlind23]

@mauri870 does this PR fixes https://github.com/elastic/ingest-dev/issues/3677? After reading the description I am not sure what the For keyword means here.

[cmacknz]

Just double checking why we need this to be an integration test that runs the entire collector. What additional test coverage is this adding? Why can't this be covered by a unit test in the exporter?

I like integration tests, they catch a lot of problems, but they are also driving our CI execution time to infinity :)

[mauri870]

Agree, I think this is better suited to be in the exporter. Actually, it might as well be covered in the exporter already by open-telemetry/opentelemetry-collector-contrib#36396. I will double check.

[mauri870]

@mauri870 does this PR fixes elastic/ingest-dev#3677? After reading the description I am not sure what the For keyword means here.

"For" in this context means "Relates to" that issue. Unfortunately the issue is an umbrella to different corner cases that need to be covered, and this PR is a test for one of them.

[mauri870]

So I looked into the tests and the elasticsearchexporter has coverage of test options, including flush::interval and flush::bytes here, I don't think an integration test in this case adds any additional coverage.