Plugin Development Framework

[Ayrdrie]

Resolves #4321

• Signed CLA.
• Associated CONTRIBUTING.md updated.

[phemmer]

Just my own $0.02 as a developer who frequently contributes: I think docker should only be used when we need to create an integration test with an external service that cannot be mocked. I personally don't want to have to install & launch docker just to perform a test that could be accomplished with go test. Like why does logparser need a docker container?

[danielnelson]

I think we should be careful to differentiate between testing and development.

Tests should use the method that adds as few dependencies and confounding factors as possible. This means favoring unittests over integration tests. Unittests should allow greater control over the test environment, pinpoint the cause of the error more accurately, are less likely to fail spuriously, and are faster to run. Integration tests, in addition to not doing those things as well, aren't ran as part of continuous integration.

I don't see this pattern being used as part of the automated tests, but it could be useful for development.

Developing plugins often requires running the real service in order to write the behavior for mocks into the unittests, and I think this is where docker can be helpful. But, like testing, development should still use the simplest method available. In the case of plugins like logparser, it doesn't make much sense to develop with docker, and we don't want it a requirement for testing. There are other situations where docker won't be helpful either, such as if you need to test a problem on a platform that is not Linux or if the service is not Free Software.

With this philosophy, I think we should reword things so that they are more development focused. It should be made clear that the docker compose files are recommended for development and that it is optional to add docker compose file when adding a new plugin.