move plugins into the gem

[ripienaar]

At present the method for installing the core plugins is a bit annoying - it makes many many file resources. I think this model has merit for user generated plugins but for the core ones we can do better.

I propose that during the building of the gem we effectively vendor the core plugins from https://github.com/choria-plugins/ and https://github.com/choria-io/mcollective-choria into the gem, the role of the puppet manifest per plugin would then be to deliver dependencies, configuration and to activate a particular plugin.

For this to make sense we have to switch these plugins to disabled by default unless activated and then by enabling the plugin on choria installs mainly they would write a configuration that activates the plugin and other settings needed.

We should also consult the activated state when loading DDLs - we shouldnt say load the shell agent DDL if the shell client is not enabled. In the past this would not be a problem because the DDL just wouldnt be there, now it would be there but we need to know to skip it.

This would kill a few 100 file resources on a typical install.

So to actually get this done we should extend the mcollective::module_plugin as below:

• specifically activate every plugin for server side and client side, we might need a new config property since there's no client activate property now
• Then vendored plugins basically just need to generate empty file lists since their files are already in core

No doubt there are more things but this should be the bulk of it and minimise changes.

In this code base we'd need to at least:

• Look for the client activate property when loading DDLs
• Potentially deactivate all plugins by default but this is a big change

We'll start with the service and the core choria plugin only when we go down this route.

[ripienaar]

Current code results in yaml serialiser being used as the documented config method to set serializer is somehow ignored.