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.
This fixes 5 issues in regard to types of values:
1) Default values for params in the metadata were not converted properly,
most visibly on integer values being loaded as double values.
2) Param values coming in from jsonrpc were not converted properly.
3) The plugin might set state values with invalid types or being out of range.
4) If, for some reason (e.g. earlier versions of nymea, or a plugin setting
its own params in code with a wrong type), there was a param value with a
wrong type in the system, we stored that wrong type and restored it on loading
of plugin params while instead it really should be converted to the specified
type in the ParamType.
5) If a plugin is not loaded for a configured thing, the old code would
not initialize the states properly but upon shutdown save those invalid
values to the cache.