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.
Note: This doesn't remove 100% of the related code yet, just keeps
the minimum required to emit autoThingDisappeared() for all the
things and clean up users setups.
The rest of the CloudNotifications class code shall be removed
with 0.31 (or soonish after that).
Getting row count on a db with approx 200000 entries on an RPi takes
about 500ms. To avoid this, this branch keeps better track of entries
in the DB and only queries DB count if we can't calculate it ourselves.
Trimming itself takes some 150ms. To reduce those calls it changes the
threshold of when to trim the DB from a fixed value of 100 to 1% of
maxDBSize.
Last but not least, getLogEntry() calls are now prioritized over
appendLogEntry() calls in order to stay responsive to client apps even
if the DB is overloaded with a huge job queue.
If the job queue grows to over 1000 jobs, logs of the same device/type
will be discared to avoid log flooding.
