Modules discovery process rethinking

[diafour]

Discovery process is now performed statically: it calculates enable state for all modules at once. The better way is to calculate first enabled module and run it, then calculate next enabled module and run it, go on until all modules are run. This, more dynamical algorithm, also helps resolve #16 and #43.

[diafour]

The idea is to make ReloadAllModules process dynamic to bring in module dependencies and immediate reaction to the changes in global values.

A preliminary plan:

• create a new task type RunOrDiscoverNextModule
• add flags NeedDiscover and NeedRun in the module struct
• RunOrDiscoverNextModule task is queued when globals values are changed or modules values are changed
• RunOrDiscoverNextModule algorythm:
  • search in allModules index the first module that needs to discover or to run
  • run this module
  • search for module again
  • if there is one, queue another RunOrDiscoverNextModule to the end of the queue. This step gives ability to execute schedule or kubernetes hooks between module runs.

Modules dependencies If a module config will have a list of after module, RunOrDiscoverNextModule tasks can be queued into different queues and modules will run in parallel.