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.
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.
This
a) makes the log db threaded by using QtConcurrent to run queries in a
different thread but still keeps ordering of the queries and always
only allows a single query at a time (QSql is not threadsafe). This fixes
removeDevice calls failing if we take more than $jsonprc_timeout to clean
a deleted device from the DB and keeps nymead responsive during that too.
b) generally improces performance of the system by not requiring operations
(emitting events, changing states) to wait for the sync log db entry to be
made.
c) drops some of the houskeeping code on nymea startup. While this will still
do log db housekeeping if the DB exceeds maxDbSize, it will not run
housekeeping on the DB any more at application startup. Reasoning for this
is that there have been reports of rules/log entries beimg destroyed if a
plugin can't be found at application startup. Given our general direction
of working towards more dynamic plugin loading, this might happen more often
in the future and we sure don't want to destroy rules etc when we just
temporarily miss a plugin.
d) tries to fix issue #226 by rotating the DB not only when it fails to open
initially, but also when it fails to insert new entries.
