Light: Add smoke testcases for Example Msg Generator source

[mitzkia]

• My goal with this PR series is to add a good test coverage (with the minimal effort) for the supported drivers in Light.
• Of course these are only a smoke testcases, which did not checks the actual functionality, but checks if syslog-ng could configure/use that option and one message could arrive from source to destination

What are the benefits:

• bigger (smoke) coverage for driver options
• this will be always actual for the all options (if a PR introduces a new option for a driver it will be automatically tested) per driver
• with the minimal testcase effort (with the help of pytest parametrize) we could write smoke testcases for drivers

What are the drawbacks:

• smoke testcases needs to maintain only in special certain cases when an option introduces a custom (or new) option type.

How this works:

• We have one API requirement from: contrib/config_option_database/utils/ConfigOptions. There is a function (get_driver_options()) which can provide all options with their option value types for a certain context (source or destination) and driver.
• For all supported drivers in Light I would add one new testcase file which can iterate in all supported options (in this PR: source_drivers/generator_source/test_generator_source_smoke.py)
• Smoke testcases needs a new option and value generator (generate_options_and_values_for_driver()). This will provide all possible options with an example value for tescases. With the help of pytest.mark.parametrize Pytest will generate a new testcase from each option and value.
• In generate_options_and_values_for_driver() we construct a list of dictionaries where one dictionary contains a configured option and value. Example: {'keep-hostname': 'yes'} or {'hook-commands': {'teardown': "'almafa'"}} . These option elements will be the inputs for testcases.
• In generate_options_and_values_for_driver() when get_driver_options() provide us an option type we will map it to a custom value. Here we need only a valid value, to check if syslog-ng could start with it.

You can check an example run here (under the Light target you can find like this: functional_tests/source_drivers/generator_source/test_generator_source_smoke.py::test_example_msg_generator_source_smoke[use-syslogng-pid_yes]):
https://github.com/mitzkia/syslog-ng/actions/runs/3476660034/jobs/5812084494
or
https://github.com/mitzkia/syslog-ng/actions/runs/3476660034/jobs/5812084655

[github-actions]

No news file has been detected. Please write one, if applicable.

[mitzkia]

This PR is depends on: #4181

[mitzkia]

These are the relevant commits for this PR:

• DevshellPipPackages: Add networkx as a new package dependency

• Light: Add option and value generator to parametrize smoke testcases

• LightGeneratorSource: Add smoke test for generator source

• tmp/workaround for GitHubActions, drop before merge

[mitzkia]

If it is needed we can 'mark' smoke testcases in Light, to enable-disable them from the actual run. But in case of GitHub Actions I would enable them to verify if a driver has not got a new regression.

[bazsi]

if we want to do this, I think this package should be moved out of contrib and probably into scripts.

If we did that, I would also try to run it from inside of the new build-time Python venv (e.g. #4193). This would mean that networkx should be added to dev-requirements.txt in the root and not here.

We might also consider dropping cleaning up/getting rid off pip_packages.manifest.

[mitzkia]

Thanks for the note.
I have rebased this PR on top of #4193 . From now this PR is depends on #4193 (how to install networkx package)
I have also replaced the commit where networkx has added. The new installation place is dev-requirements.txt file in the root.
After this new smoke testcases could run successfully for me.
If I am correct @alltilla has future plans with config_option_database. Could you please help a little for us?