OPTIONALLY Report last original data refresh timestamp and "Data Stale" criteria among NUT readings for a device/driver

[jimklimov]

An idea that came up in discussion is that we have a "Data stale" concept, but do not really know when the last updates were. So...

• Add global and general driver-level settings (also augeas, C++/nutconf...) to enable this report, keep it off by default (assuming it may be some sort of security leak to make server/service timestamp/uptime known)
• The setting should say which time we actually want reported:
  • System/OS timestamp, driver uptime (e.g. same as used in upsdebugx() logging), system/OS uptime (monotonous clock where available)?
  • For some cases it is enough to see a value changing, could even be just the main-loop count.
  • Is it a number (e.g. epoch seconds where wall-clock time is used - 64-bit time then?), and which - rounded or floating (sec, sec.subsec, or integer msec/usec precision times), or an opaque string (so ISO timestamps or numbers as fit)?
• Some drivers have the concept of full vs. quick updates, or individual values coming by interrupt. Maybe we want to discern that in separate reported fields, current candidate is driver.lastupdate(.full|.quick|...?) following the driver.state precedent.
• Expose what is "too old" (when would the driver state its data is stale?) if we have a run-time number for that?
• Expose since when/how long the data is stale when it is?
• Formally define corresponding docs/nut-names.txt entries

Among useful aspects, NUT data consumers could read this value and decide whether to process the rest of info (similar to HTTP-304 "Not modified"); in that case it may make sense to report it first (out of alphanumeric order? assign a name pattern that is early in the alphanumeric list?) CC @aquette : could this help conserve some processing loops in your SmartNUT effort with weak devices (if any expected)?

Also note that (IIRC, to check) internally all dstate values should track their individual last-update timestamp; following this idea a (separate) setting may be reasonable to expose that. Probably useless generally, but can help in troubleshooting and development. Naming-wise, this could be a namespaced like driver.lastupdate.debug.<reading.name>. Maybe these should be exposed (if enabled) even if data is considered stale.