lazy status updates

[emiltin]

fixes #189

uRt=0 and sOc=false indicate lazy updates: the attribute is only send if another attribute trigger an update.

[emiltin]

More background on this PR:

The existing subscription mechanism, each attribute you subscribe to is treated individually with it's own updateRate and sendOnChange.

For example, the TLC S0001 status is used to get signal group status: https://rsmp-nordic.github.io/rsmp_sxl_traffic_lights/1.2.1/sxl_traffic_light_controller.html#s0001

'signalgroupstatus' provides the actual signal group status as a string, e.g. "FF3FFF0". 'cyclecounter' provides the cyclecounter in whole seconds, e.g. 14.

Sometimes what you want is to get an update every second with the cyclecounter. You cansubscribe with updateRate=0 and sendOnchange=true for both attributes, and get updates like:

cyclecounter=0, signalgroupstatus="FF3FFF0" # here signal groups status changed
cyclecounter=1
cyclecounter=2
cyclecounter=3, signalgroupstatus="33300FF" # and it changed again here
cyclecounter=4
...

My understanding is that the signalgroupstatus attributes is NOT included when only the cyclecounter changes? I checked how the rsmp gem behaves, and that's how it behaves. So a TLC should not be sending repeated signalgroupstatus data.

But often you want an update just when the signalgroupstatus change, and then want the cyclecounter to be included. But there's currently no way to do that. The proposal in this PR makes it possible by subscribing to signalgroupstatus with uRt=0 and sOc=true, and to cyclecounter with uRt=0, sOc=false. You would get something like:

cyclecounter=0, signalgroupstatus="FF3FFF0" # here signal groups status changed
cyclecounte=3, signalgroupstatus="33300FF" # and it changed again here
...

This is even more important when we increase the cycle counter precions. You don't want 10 status updates per second just to get a cyclecounter. But you DO want a high precision cyclecounter value when the signal group status changes.

Lazy updates are trigged when another attribues in the same status message changes. For example, a change in S0002 cannot trigger an update for S0001.

[marcgarba]

Interesting and simple concept that will allow to get many attributes in the 'same' RSMP message, with just some attributes driving the subscribing conditions.

On the other hand, the word 'lazy' doesn't necessarily speak for itself...

[emiltin]

S0001 signal group status cyclecounter, uRt=0, sOc=false => lazy updates signalgroupstatus uRt=0, sOc=true

1. is lazy attributes send along with attributes that are send with a regular interval (uRt) => yes
2. is lazy attributes send also when there are no change to that lazy attribute? => yes?
3. no sub, lazy or uRt/sOc

Lazy attributes are send when another attribute change - within the same status (status code).

A higher resolution cycle counter could either be in a fixed resolution like 10th of second or milliseconds, or we could use a float.

"rrrggg" 333 # nearest millisecond, as an integer "ggggA" 0.333333333333333333 # a float could include a lot of decimals, that are probably not needed?

cyclecounter: existing attribute providing cycle counter in whole seconds cyclecounter_ms: the cycle counter expressed in milliseconds, wrapping around. cycle counter could sometimes be stopped clock_ms: the internal clock in ms, not wrapping around, never stops