[8.19](backport #51940) Set shutdown timeout for beat receivers to 5s by default

[mergify]

Proposed commit message

Set shutdown timeout for beat receivers to 5s by default.

Beat receivers need a longer timeout than the default 1s, as it needs to exceed the batcher flush timeout. The current code gives the impression of this already happening, but in reality, if the beater handles pipeline shutdown on its own, the default timeout wins.

The PR adds the default in NewBeatForReceiver and adds a test for filebeat receiver which asserts that the timeout is at least 5 seconds.

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. Where relevant, I have used the stresstest.sh script to run them under stress conditions and race detector to verify their stability.
• [ ] I have added an entry in ./changelog/fragments using the changelog tool.

Related issues

• Relates [Flaky Test] Fix TestMonitoringNoDuplicates flakiness elastic-agent#15514

---

This is an automatic backport of pull request #51940 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 8f4bbab has failed:

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

You are currently cherry-picking commit 8f4bbab77.
  (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)

Changes to be committed:
	modified:   x-pack/libbeat/cmd/instance/beat.go

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   x-pack/filebeat/fbreceiver/receiver_test.go

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

Both failed Buildkite jobs are reporting the same deterministic pre-commit failure: x-pack/filebeat/fbreceiver/receiver_test.go still contains unresolved cherry-pick conflict markers. This is a backport conflict, not an infrastructure or test-runtime failure.

Remediation

• Resolve the conflict in x-pack/filebeat/fbreceiver/receiver_test.go, preserving the 8.19 branch changes and the backported receiver tests as appropriate; remove all <<<<<<<, =======, and >>>>>>> markers.
• Re-run pre-commit run --all-files (or the two affected Buildkite pipelines) after committing the resolved file.

Investigation details

Root Cause

The PR is an automatic backport of #51940 and is marked with a conflicts label. The PR diff contains conflict markers in x-pack/filebeat/fbreceiver/receiver_test.go: import conflicts at lines 21-25, a conflict block beginning at lines 503-504, and its closing marker at line 789.

Evidence

• Build: https://buildkite.com/elastic/beats/builds/49444
• Jobs: beats-xpack-dockerlogbeat build https://buildkite.com/elastic/beats-xpack-dockerlogbeat/builds/29349 and beats-xpack-agentbeat build https://buildkite.com/elastic/beats-xpack-agentbeat/builds/1493
• Both jobs run pre-commit run --all-files and fail in check-merge-conflict with: x-pack/filebeat/fbreceiver/receiver_test.go:21: Merge conflict string u003cu003cu003cu003cu003cu003c found, ...:22: Merge conflict string u003du003du003du003du003du003du003d found, ...:25: Merge conflict string u003eu003eu003eu003eu003eu003eu003e found, plus markers at lines 503, 504, and 789.

Verification

Not run locally because this workflow is read-only and the failure is directly identified by the pre-commit output.

Follow-up

After resolving the conflict, regenerate/update the PR branch so the backport is no longer blocked before retrying CI.

---

What is this? | From workflow: PR Buildkite Detective

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