Cleanup: Stop using the global plugin registry for the Beats manager

[faec]

This PR is a functional no-op, it merely simplifies some initialization code.

The code being modified handles the creation of the Beats Manager object. When linked with x-pack, this object should be created by NewV2AgentManager, and otherwise it should be an empty placeholder. These are the only possible values, except for some unit tests that replace it with a mocked version.

Despite the relatively simple functionality, the current code goes through some heavily abstracted steps:

• Create a plugin object, which accepts a configuration [which is ignored] and vends a factory function
  • In the factory function, create a Manager object based on factory parameters
• On package initialization, register the plugin object in the global feature registry using the namespace "libbeat.management"
• When a Manager object is needed, query the global feature registry for all entries under "libbeat.management" and look for a plugin that can accept the given configuration. If one is found, use it to create an appropriate factory
• Immediately invoke the resulting factory to create the actual manager.
• In the tests, when a mocked manager object is needed, scan the global registry and remove any existing "libbeat.management" entries; then add a mocked equivalent to the registry so it is picked up during initialization.

...all to correctly invoke an initialization function that in live code can only ever have a single globally unique value, known at build-time.

This PR removes that machinery and replaces it with a single global variable protected by a mutex. Updating this variable for x-pack or unit tests now involves simply calling the helper management.SetManagerFactory instead of working with the feature registry to create or scan a list of plugins. The manager is now created with management.NewManager instead of the indirection of a factory that is immediately invoked by the caller.

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

[faec]

Hmm, not sure what to make of the linter error "github.com/elastic/go-sysinfo/types" imported and not used (typecheck) since that package is in fact used in that file. That lint error doesn't reproduce for me locally either.

[faec]

/test

[faec]

I still don't know what's going on with the linter but some of the other test failures are real, I'm investigating

[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-29T20:12:55.423+0000

• Duration: 70 min 5 sec

Test stats 🧪

Test	Results
Failed	0
Passed	26087
Skipped	1969
Total	28056

💚 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!)

[faec]

I believe I found the problem -- my code wasn't checking Enabled() so it was returning a live manager in some settings where it shouldn't.

While fixing that I made a few more cleanups (I removed the UUID from the factory interface since nothing used it; I also made the factory invocation internal to the management package, so now clients just call NewManager instead of requesting a factory.)

[fearful-symmetry]

This looks pretty reasonable to me.