name all k8s workqueue

[newly12]

Enhancement

What does this PR do?

name all k8s workqueue accordingly

Why is it important?

we have metricbeat running with autodiscover enabled to collect metrics from all pods in the entire cluster, we noticed that in some large clusters(in our case tens of thousands of pods) autodiscover is "slow", for example a new pod could take very long time or forever for metricbeat to start scrapping, however it can be seen after restarti metricbeat for several minutes. we add done these code changes and then leverage the default metrics instrumentation done by controller runtime and identified that there were many items pending on processing in the "pod" workqueue.

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.

Author's Checklist

• queue name is essential for its metrics instrumentation

How to test this PR locally

Related issues

Use cases

get insights into beats' k8s workqueue

Screenshots

Logs

[mergify]

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

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

NOTE: backport-skip has been added to this pull request.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2021-11-03T01:37:11.841+0000

• Duration: 124 min 5 sec

• Commit: b6ff463

Test stats 🧪

Test	Results
Failed	0
Passed	53550
Skipped	5225
Total	58775

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[ChrsMark]

/test

[ChrsMark]

lgtm, left one minor

[MichaelKatsoulis]

NewWatcher is also used by elastic-agent Kubernetes provider. If we continue with the named watcher approach which is a useful addition we should consider updating agent too so that we won't need both functions. This could be part of a separate PR

[MichaelKatsoulis]

/test

[MichaelKatsoulis]

LGTM! Thanks a lot @newly12. Let's wait CI to be green and then we will merge it!

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b k8s_work_queue upstream/k8s_work_queue
git merge upstream/master
git push upstream k8s_work_queue

[MichaelKatsoulis]

@newly12 Can you resolve the conflicts in the CHANGELOG.next.asciidoc ?