Enh: Add module manager test and add some improvements and bug fixes

[martin-rueegg]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Tests

Please have a look at the commit titles to get an idea!

Does this PR introduce a breaking change?

• Unlikely. There are some return types added to ModuleManager though.

If yes, please describe the impact and migration path for existing applications:

• a developer would have to adapt their inheritance of ModuleManager if they use a custom Manager in their setup or for the module itself.

The PR fulfills these requirements:

• It's submitted to the develop branch, not the master branch if no hotfix
• When resolving a specific issue, it's referenced in the PR's description (e.g. Fix #xxx[,#xxx], where "xxx" is the Github issue number)
  Would it make sense to create different issues for documentation/tracking purposes?
• All tests are passing
• New/updated tests are included
• Changelog was modified

Other information:

[martin-rueegg]

@luke-,

While writing a test case to test the ModuleManager I came across a anomailty:

While registering modules, there is no test if the module is inheriting from \humhub\components\Module. However, in many other places, the module will fail if it does not do so, e.g. in

• getModules(),
• filterModulesByKeyword (class is not tested, but methods are accessed that do not exist in \yii\base\Module)
• enable() and disable() require this type in the parameter
• enableModules() and disableModules()

I would suggest to test for either that inheritance, or even better to create an interface that needs to be met (which is to be implemented by \humhub\components\Module, of course).

[martin-rueegg]

Requested changes applied!

@luke-, how would you like the CHANGELOG to be ammended? I guess it makes sense to have more than one line. Shall I create issues or add multiple lines with the same PR number, in order to document the separate the changes?

[luke-]

@martin-rueegg As you like, but probably it is easier to add several lines with the same PR number.

Is it sufficient for you if we merge this PR into v1.16? I would like to minimize changes to the current beta as little as possible.