[9.3](backport #50563) chore: update OTel Collector dependencies to v0.151.0/v1.57.0

[mergify]

Proposed commit message

Updates the OpenTelemetry Collector dependencies to the current latest versions v0.151.0 and v1.57.0. See changes since v0.150.0/v1.56.0 for Core and Contrib.

Why is it important?

We want to be on the latest version to keep up with latest features and bug fixes.

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.next.asciidoc or CHANGELOG-developer.next.asciidoc.

How to test this PR locally

make mage
(cd auditbeat && mage build)
(cd filebeat && mage build)
(cd metricbeat && mage build)
(cd x-pack/filebeat && mage build)
(cd x-pack/metricbeat && mage build)
```<hr>This is an automatic backport of pull request #50563 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 79a0485 has failed:

On branch mergify/bp/9.3/pr-50563
Your branch is up to date with 'origin/9.3'.

You are currently cherry-picking commit 79a048584.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   NOTICE.txt
	both modified:   go.mod
	both modified:   go.sum

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
• /test : Run the Buildkite pipeline.

[infra-vault-gh-plugin-prod]

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

[github-actions]

TL;DR

All 33 Buildkite failures are caused by unresolved merge-conflict markers committed into go.mod and go.sum on mergify/bp/9.3/pr-50563 (f23418fc641e489ba9d32dbc46e4b16aa3140b5b). Resolve those conflicts and regenerate module artifacts before re-running CI.

Remediation

• Resolve all conflict blocks in go.mod and go.sum (remove <<<<<<<, =======, >>>>>>> and keep the intended dependency set).
• Run go mod tidy from repo root, then regenerate any dependency-derived files touched by this PR (notably NOTICE.txt) and push the updated backport branch.
• Re-run Buildkite (/test).

Investigation details

Root Cause

This is a configuration/integration failure from an incomplete cherry-pick conflict resolution (not a flaky infra issue): the PR branch itself contains conflict markers in module files.

Confirmed on PR head content:

• go.mod:201 contains <<<<<<< HEAD
• go.mod:203 contains =======
• go.mod:206 contains >>>>>>> 79a048584 ...
• Additional conflict blocks at go.mod:247, go.mod:324, go.mod:473, go.mod:528
• go.sum:1323 contains <<<<<<< HEAD
• go.sum:1326 contains =======
• go.sum:1331 contains >>>>>>> 79a048584 ...

These markers directly break both CI entry points:

1. pre-commit run --all-files fails check-merge-conflict
2. make -C <beat> check update fails early because go cannot parse go.mod

Evidence

• Build: https://buildkite.com/elastic/beats/builds/45643
• Representative job/step: Filebeat: Run pre-commit
  • go.mod:201: Merge conflict string '<<<<<<<' found
  • go.sum:1323: Merge conflict string '<<<<<<<' found
• Representative job/step: Auditbeat: Run check/update
  • ../go.mod:201: malformed module path "<<<<<<<": invalid char '<'
  • make: *** [../dev-tools/make/mage-install.mk:10: mage] Error 1

Because every failed job is running against the same repo state, this single root cause fans out to all 33 failures.

Verification

Not run locally in this workflow (read-only detective analysis based on Buildkite logs and PR head file contents).

Follow-up

After resolving conflicts and pushing, if any failures remain, they should be actionable as second-order issues once module parsing succeeds.

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[mergify]

This pull request has not been merged yet. Could you please review and merge it @andrzej-stencel? 🙏