Rules in alert_device:275 can be generated, sent and processed many times over

[jimklimov]

While brainstorming bottlenecks, we found that the publishRule routine sends (potentially) updates of rules based on data collected from NUT devices. There is some protection from extra load, in the form of tracking in an alert object that its last state has been published and received by the counterpart (as "OK" or "ALREADY_EXISTS" confirmation).

Still, logs say that the "ALREADY_EXISTS" events happen quite often. Also, the act of determining that the new rule is same as an already known one requires to process the received string and compare to existing data on the receiving side (as well as to generate that string with equivalent content or on fty-nut side in the first place).

Ideas of improvement include:

• if we must generate the string on sender, we can also generate a hash of it and send it as part of the (multipart?) message; the receiver can then compare the old hash to new one and quickly not-process the same payload;
• track better if we need to generate a new string that would end up being same as old one, so meaning to track the changes of variables which go into it via zsys_sprintf. Those are mostly fields of a DeviceAlert struct instance ((low|high)(Warning|Critical)) accessed directly -- work with those could be changed to (inline?) getters/setters in a class, with the latter taking care of refreshing the alert's rulePublished flag depending on whether the value actually changed.
• Alternately, instead of making DeviceAlert into a class, we can revise the lifecycle of those struct instances. Currently there is an addAlert() that adds a new alert (or bails if one for such data point "quantity" exists already), and a scanCapabilities() that starts by dropping the old list of _alerts. So whenever we scan, we get a new list of items marked unpublished, even if their values (supported alerts) are same as known before. Probably, the scan could end with dropping obsoleted _alerts, tracking in a new field (reset at beginning of scan for all existing entries) whether the entry was not refreshed by the current scan or making a copy of the list and comparing the old and new lists, etc. This way alerts known previously will not disappear after a scan, alerts not found by a scan will be removed later, new alerts will be added, and really modified alerts updated. During this operation, we are in position to update the rulePublished flag during AddRule() processing, similarly to the setter methods in a class approach.
• As a side point, the publishRule() accesses .c_str() of the same string objects many times, some readability and maybe runtime performance might improve if we cache those into char * variables made once.