introduce further handling and notifiers for ALARM status

[desertwitch]

As outlined in #2657, dstate.c sets ALARM as a common denominator status when encountering ups.alarm variables reported through the different device-/manufacturer-specific implementations within the UPS drivers. Previously a user had to either rely on audible alarms by the UPS or (in an unattended setting) periodically check the UPS status and variables manually to be informed of potentially severe UPS device alarm states/conditions.

This pull request introduces ALARM status handling in upsmon as the remaining piece of the puzzle to effectively act upon UPS device alarms as raised by the UPS drivers. This includes notifiers ALARM and NOTALARM for when the status is encountered and dissipates, respectively, allowing the user to now configure notifications and tasks e.g. through upssched.

By default upsmon will treat any encountered ALARM status as (potentially) severe enough to warrant an UPS being promoted to critical in a no-communication situation. This can, however, be unwarranted due to there being no common standard for what constitutes an alarm. In fact mundane alarm states were previously observed with UPS devices in HE/ECO mode, which could lead to unwarranted shutdown situations on minor connection hiccups. For this reason a 0|1 setting ALARMCRITICAL was introduced into upsmon.conf, for such users to be able to prevent upsmon from treating the ALARM status as overly severe when it's not.

As for the default behaviour (of considering such an UPS as volatile) erring on the side of caution seemed to be reasonable, as e.g. an alarm for some failing circuitry and the affected UPS later dropping offline should be concern enough for the UPS to be considered immediately critical and the system pre-emptively being shutdown e.g. by reduction/depletion of MINSUPPLIES.

fixes #2657

[desertwitch]

For further improvements down the road, perhaps we should also consider tracking ups.alarm variables and produce logs for newly registered alarms and later cleared again alarms respectively (although this would be more suitable in direction of dstate.c and/or the drivers, rather than within upsmon, but it would be nice to have a unified/common denominator solution in spite of different driver-side implementations... similar to as done with the ALARM status, so perhaps in dstate.c as well?). This would complement the upsmon side of handling things (as introduced by this PR) well, where the status is handled but not the individual alarm messages/variables. But this is, I think, outside the scope of this upsmon-specific PR.

[jimklimov]

Thanks, I hope to have some time to look at it this week. So far it started very intensively.

[desertwitch]

Thanks Jim, it's no stress at all, I've taken the liberty to broaden the scope here a bit where it made sense. 😉

[AppVeyorBot]

❌ Build nut 2.8.2.2247-master failed (commit f8aaf4c1ea by @desertwitch)

[AppVeyorBot]

✅ Build nut 2.8.2.2248-master completed (commit f3f2049828 by @desertwitch)

[AppVeyorBot]

✅ Build nut 2.8.2.2282-master completed (commit f3f2b3361b by @jimklimov)