Refactor queues to be initialized explicitly instead of through global registry

[faec]

This is an entirely internal change to the queue initialization, it should have no visible effect.

Historically, queues have been registered in a global lookup table based on their configuration name, and dynamically created on Beats startup by querying the registry for the appropriate factory.

This already had some drawbacks in the past: complexity-wise, a dynamic global registry is some heavy lifting to account for exactly two possible values, and even in those two cases the factory methods used were not appropriate since the disk queue and memory queue took different parameters on creation (previously the disk queue handled this by ignoring factory parameters that didn't apply to it).

However, we will soon need to accommodate a third possible configuration (#34396). In this configuration, the queue type depends on the selected output, which is generally not known during Beats initialization (under Agent, beats are typically started with no output, and then receive their output in a second configuration pass via (*BeatV2Manager).reloadOutput). This means that we will need to be able to create or modify the queue after initialization.

This PR does not go that far -- it's just a preparatory cleanup to make the impending refactor easier. This PR removes the queue's use of the global registry and associated factory methods. The code in module.go that used to handle the registry lookups now instead has explicit queue creation logic, which is clearer and will be easier to refactor into a more dynamic form in followup work.

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.

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @faec? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

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

[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: 2023-03-28T15:15:03.215+0000

• Duration: 69 min 44 sec

Test stats 🧪

Test	Results
Failed	0
Passed	26077
Skipped	1965
Total	28042

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the 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.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)