Restructure MQTT config distribution

[hikinggrass]

• publish manifests individually on retained topics instead in one big blob
• change module/impl config entry format to include its type, this removes the need for the whole config schema just to determine the type
• reorder the config handler before the ready handler in manager to reflect the order of operations taken during initialization of a module
• smaller optimizations

[corneliusclaussen]

retained topics: Could this lead to potential left-over problems of previous EVerest runs? In the default mosquitto config it is even stored permanently surviving reboots. Is it ensured that there can't be race conditions where e.g. one module subscribes to mqtt before the manager publishes the new config?

[hikinggrass]

retained topics: Could this lead to potential left-over problems of previous EVerest runs? In the default mosquitto config it is even stored permanently surviving reboots.

Yes, and this is partially addressed with #233 (at least for successful starts, there is be more cleanup needed in cases the manager exits early, I'll address this over there). However the retained topics behavior is already in v0.19 and v0.19.1, so #233 is already an improvement as is

Is it ensured that there can't be race conditions where e.g. one module subscribes to mqtt before the manager publishes the new config?

For configs this should not be an issue since a module explicitly requests a config from the manager and this doesn't involve retained topics. For manifest/interfaces/etc. there may be scenarios where this is a problem. It seems pretty stable thought (eg. I run the ocpp-tests of everest-core in parallel with all cores of my machine reliably all the time) but I will investigate this a bit further

[corneliusclaussen]

just a random thought: would it make sense to clear those topics as a last will from the manager?

[hikinggrass]

just a random thought: would it make sense to clear those topics as a last will from the manager?

yes, sounds like a good idea. I plan on opening a PR with some signal handling for the manager that could then trigger this as well. During normal operation #233 will clean them up after every module is ready