Fix packaging of OSS light modules

[jsoriano]

What does this PR do?

Move light modules packaging code in Metricbeat to common methods for X-Pack and OSS, so they are properly packaged in both cases.

Add a check to OSS metricbeat packaging test to check that it includes at least one light module.

Why is it important?

Metricbeat 7.6.0 includes OSS light modules, but they are not being packaged.

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

How to test this PR locally

• Check that OSS Metricbeat packages include OSS light modules, but not X-Pack light modules.
• Check that X-Pack Metricbeat packages include OSS and x-pack light modules.

Packages can be built with mage package

Related issues

• Needed to release [Metricbeat] Add Kafka JMX metricsets #14330

[jsoriano]

run beats-ci/package

[sayden]

LGTM. Let's move this forward but I'd like a follow up PR where this is polished a bit.

Functions names like prepareLightModules(path... string) error are a bit obscure at first sight. Specially when its comment states generate wich is not the same than prepare and in both cases are vague descriptions about what the function is doing. If "preparation" is about "cleaning", "creating folders", "going through paths for something" and then executing tasks... this is a lot to describe it with prepare.

Same with calls like devtools.WithModulesD or lightModulesPackaging(). The latter is particularly obscure because it uses a global variable, which implies that testing is going to be tricky. Why it cannot be passed as dependency? Don't answer me, it's a rethorical question 😄 I mean that it must be clear in the code and/or comments

Just trying to be constructive 😉

[jsoriano]

@sayden thanks! I have renamed some helpers to be more consistent with the naming in the rest of magefiles.

There are still some things that could be refactored apart of the ones you mention, for example customizeLightModulesPackaging and CustomizePackaging could be actually merged, but I didn't want to touch CustomizePackaging now. And all these CustomizePackaging methods could probably benefit of more code reusal between different beats.

Regarding the use of prepare, it is common in our magefiles to prepare files to be packaged (this implies copying files and creating directories, yes), if we change it we need to review its use in all beats. The use of constants (is this what you refer as global variable?) for paths is also common in these files, I am ok with commenting or renaming them if they are not clear.

[jsoriano]

run beats-ci/package

[jsoriano]

Umm, I have merged it (2cde4ce) but the issue hasn't been updated, closing it.