This moves all the things and rules logic away from NymeaCore
into their respective modules where it belongs.
One major change is the removal of the removePolicy functionality.
This was somewhat broken as it was only working for rules but not
for all the other modules like scripts, experiences etc. After
an attempt to create something that works with all modules it
really seemed that this does not make a lot of sence after all,
given that updating rules would in most cases leave something
very broken behind and removing them was the only sane thing to do.
On the other hand, experience plugins may not work well with such
a policy eithre as they may require to do their own special thing.
So in the end the removePolicy was dropped altogether. Apps should
instead figure out themselves what removal of a thing may imply and
inform the user about that beforehand.
If the same directory is passed twice QPluginLoader
would return the same object for the instance() call.
Deleting that would lead to deleting the instance for
the originally loaded plugin too.
Up until now, nymea would generate EventTypes for every StateType
as well as emit an Event (along with a StateChanged notification) for
every change. This results in a lot of duplicated network traffic
which is of not much use. The StateChanged notification contains
all the information in the Event too and nymea:app actually never
really used Events for state changes.
This commit removes the events from the ThingClass, making it a lot
smaller and stops emitting Events for state changes.
As this is breaking the behavior, the JSONRPC API major version
is bumped.
Reasoning:
a) Currently, the API behaves inconsistently. While reconfiguring
a "justAdd" thing, it did call thingRemoved, however, reconfiguring a thing
that uses pairing did not.
b) The old implementation did not consider childs. Reconfiguring a
justAdd thing which has childs was calling thingRemoved on the parent only
but not its childs.
c) If we'd fix this by calling thingRemoved() for all flows and childs
we'd end up in hells kitchen as we can't know about the new state of childs
after the reconfiguration, so we can't just automatically add all the childs
back ourselves, the plugin needs to do that. This in turn would mean that
childs would get new ids which then breaks rules and stuff.
So the conclusion has been to just re-run the setup and the plugin implementation
is in charge for then checking the existing childs and calling autoThingDisappeared()
as needed.
WARNING: This also implies that we need to fix some plugins which currently rely
on thingRemoved to be called for reconfiguration and might create duplicate
connections or similar now.
