Energy use collection logic

Attached is the energy accounting patch that Martin and Yiannis have been working.  The framework is there, but the functionality it currently not working.  They are both on vacation this week and then are back a week before the conference.  I thought it would be better to send in order to get the framework and the structures in place for an official 2.5.0 instead of waiting.  If you disagree, just let us know and we can send it again when the low level functionality working.    Here is a short summary of our test results.

1. jobacct_gather/none + energy_accounting/none

Looks OK.  Did not find any errors.

2.  jobacct_gather/linux or cgroup + energy_accounting/none

Looks OK.  Did not find any errors.

3.  jobacct_gather/linux or cgroup + energy_accounting/rapl

Slurmd aborts when you run a job that uses a node that does not support RAPL.  This appears to be because of the error()/pexit() at line# 150/151 in energy_accounting_rapl.c.  We need to change this code to just issue a debug message and return.  For now, energy_accounting must not be configured if the cluster includes any nodes that do not support RAPL.

The cpu frequency values reported by jobacct_gather are not correct.

Again, there are obviously some problems, so if it would be better to wait for full functionality just let us know.  It may be three weeks before they are able to spend some time on this to fix the problems, so that is why I thought you may prefer to have something that has the correctly data structures in sooner rather than later.
Patches to energy consumption logic

Fix to some un/pack logic
Fix to test12.5 for new sacct help format
Address various compiler warnings
Energy plugin mods

Minor format changes including removing changes from master code base that
are not needed (e.g. blank lines added or removed)
Energy accounting modules, add new modules
energy accounting: Add new modules
Energy plugins: add new web page
Energy accounting patch enhancements

provides the following improvements on the energy accounting framework :
1)the per step average frequency is now calculated correctly and may be reported by sstat and sacct
2)correction on the logic of per step energy consumption calculation through rapl plugin. This value may be also reported through sstat and sacct
3)node power and energy monitoring now working correctly through rapl plugin.
Purely cosmetic modifications for new energy consumption code
For accounting, correct data types in read of /proc
Rename energy_accounting to acct_gather_energy
More rename and move common vars into structure
(removed some unused variables but many remain)
cleanup whitespace
update to newer way to make plugins
remove extra return for the acct_gather_node_msg
The parameters of acct_gather_energy_p_get_data were reversed.
Cosmetic change, put signals in alphabetic order
Cray - Document signal handling with respect to ALPS reservations
Modify default log timestamp pto conform to RFC 5424 format

the attached patch changes the default timestamp format in logfiles to conform to RFC 5424 (the current version of the syslog RFC). It is identical to the current default "ISO 8601" timestamp used by slurm, with the exception that the timezone offset is appended. This has the benefits of

1) It's unambiguous.

2) Avoids potential confusion for admins running cluster(s) in different timezones.

3) Might help debug issues related to DST transitions. (More on that later..)

(To be pedantic, a RFC 5424 timestamp is still a valid ISO 8601 timestamp, but the converse is not necessarily true. So there is RFC 3339 which is a "profile" of ISO 8601, that is a subset, recommended for internet protocols. The RFC 5424 timestamp, in turn, is a subset of the RFC 3339 timestamps.)

The previous behavior of can be used by running configure with the

--disable-rfc5424time

flag.
Fix recently bug determining system topology
Avoid broken-down time in multifactor priority plugins

we recently saw an issue where on a couple clusters the age priority of almost all jobs had been zeroed. Restarting slurmctld did "solve" the issue, though I'm not really sure why it occured in the first place. One suspicion is that it was due to the recent DST transition (occured on Oct 28th over here), and that this somehow wedged the calculation of the age priority.

Looking at the code, I couldn't really find any obvious fault, but anyway, by avoiding the usage of broken-down time (which includes DST information) in the calculation of the start_time this sort of bug could at least be avoided.

The attached patch implements the above for the priority multifactor plugins.