Convert a slurmctd power management data structure from array to list in
    order to eliminate the possibility of zombie child suspend/resume
    processes.
bug 3516

Bug 3523.

NO_VAL is no longer set; it's NO_VAL64 now on memory values.

This now matches the behavior documented in sbatch.

This resolves a problem where the maximum cpu frequency would be set
to the minimum available on the node by the batch step. This is due
to the batch step leaving cpu_freq_{min,max,gov} uninitialized to zero,
which is then translated to a request to set the frequency to the lowest
available in the node. This did not impact 16.05 or earlier, as a request
for a zero frequency was ignored by a quirk of _cpu_freq_freqspec_num.
This quirk was removed by commit f40e1c01 before 17.02.0-rc1.

Bug 3510.

Update commit e58c2282 in order to
  take advantage of new functions and variables available in version
  17.02.
bug 3516

bug 3516

from 10 to 100.
bug 3516

# Conflicts:
#	src/slurmctld/job_mgr.c

Looks like there were other places not locked.

Bug 3515

information about a job to scontrol.

cause potential deadlock when/if TRES changed in the database and the
slurmctld wasn't made aware of the change.  This would be very rare.

The lock was originally there to keep new jobs from grabbing the assoc
information.  If the lock was done afterwards the worst case is we get the new
information.

It was determined we didn't need the write locks on the job and no locks were
needed on the node either.

Doing these different locked beforehand would create a window where you could
get a config write lock

Bug 3507.

This will be triggered after either a burst buffer job_begin function
  or select plugin job_begin function fails. Without this change, the
  "squeue -i" and "scontrol show job" commands can report old job
  state information.
bug 3504

Burst_buffer/cray - Prevent slurmctld daemon abort if "paths" operation
    fails. Now job will be held.
bug 3504

bug 3182

bug 3473