Does optimization of resource allocation for GRES with topology
Similar to changes already added to select/cons_res.
bug 410

Partitial reversal of commit 16143b0f
bug 403

Additional work for 6f50943c
This fixes some more GRES allocation test cases

Previously would reference NULL pointer
bug 403

Change trigger_state_restore() return type from int to void.
This eliminates some CLANG errors
bug 403

As reported by CLANG
bug 403

Fix problem reported by CLANG
bug 403

bug 403

Should not be possible, but prevent CLANG error
bug 403

Reported by CLANG, but not possible in practice
bug 403

Should not be possible, but this prevents CLANG error
bug 403

Should not be possible, but fixes CLANG bug report
bug 403

buf 403

bug 403

bug 403

Not likely, but fixed problem reported by CLANG tool
bug 403

bug 403

For a system with hyperthreads and GRES bound to specific CPUs,
there was an error in assigning CPUs

Previous logic would allocate job resources on such a node
rather than reject the job allocation on that node.

Previous logic would pick CPUs then
reject jobs that can not match GRES to the allocated CPUs. New logic first
filters out CPUs that can not use the GRES, next picks CPUs for the job,
and finally picks the GRES that best match those CPUs.
bug 410

No change in logic, just rename a variable for greater clarity

Eliminate extra variable and avoid changing the contents of a string
Minor refactoring of commit fa0af103

None of these have ever occurred, but these changes will harden Slurm
bug 403

Report anything that is world writable.

Directories created for executables, libraries, etc. have permissions
based upon the umask, which may not be desired.

/* Current code (<= 2.1) has it so we start the new
 * job with the next step id.  This could be used
 * when restarting to figure out which step the
 * previous run of this job stopped on. */

See
https://groups.google.com/forum/#!topic/slurm-devel/j4izr0L4w8w

due to multiple free calls caused by job arrays submitted to
multiple partitions. The root cause is the job priority array
of the original job being re-used by the subsequent job array
entries. A similar problem that could be induced by the user
specifying a job accounting frequency when submitting a job
array is also fixed.
bug 401