Introduce optional sd_notify() support for READY, RELOADING and STOPPING states, and a WATCHDOG (if enabled)

[jimklimov]

Closes: #1590

While the systemd notifications are first/primary cause of this change, I tried to implement it in a somewhat abstract manner to allow easy extension to other service management frameworks. No strong opinion yet if this should supplant existing (currently nearby) upslogx() or upsdebugx() messages about the lifecycle milestones.

While the watchdog notification support was added, it is currently not configured by the service unit templates (something to do more exploration about to provide decent timeouts, even for busy systems). One idea for the future was to use WATCHDOG_USEC=<NUM> (and EXTEND_TIMEOUT_USEC=<NUM>) messages for drivers (daemons) to actually tell systemd that they want to be watchdogged, e.g. based on optional maxstartdelay setting parsed from ups.conf. For example, full SNMP walks can take a while, tens of seconds or more, and wall-clock times depend on stress and performance of both the monitoring system and UPS interface hardware.

Other NUT units, such as NDE script's service (and related path), are not covered by this change at this time.

Loosely related to #1771 (might conflict a bit). Not sure if this general daemon lifecycle notification support should also get peppered into drivers as thoroughly (e.g. track reconnection attempts as a "reloading" state).

CC @bigon

[jimklimov]

Nice, status messages work - as well as MAINPID setting for systemd to monitor the intended upsd/upsmon/driver process after all the forking involved in starting one:

* nut-server.service - Network UPS Tools - power devices information server
     Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Sat 2023-01-07 18:43:17 CET; 19min ago
    Process: 4102332 ExecStart=/usr/local/ups/sbin/upsd -FF (code=exited, status=0/SUCCESS)
   Main PID: 4102332 (code=exited, status=0/SUCCESS)
     Status: "Signal 15: exiting"
        CPU: 4ms

A call to systemctl start nut-driver@eco650 only exits after driver initialization and just before entering the infinite processing loop (where it notifies the READY state to systemd).

[jimklimov]

Fixed watchdog integration per comments from @poettering and rebased over recent master branch. Hopefully this burst of activity is done :)