Original logic was testing against number of available CPUs on a
node, not the number actually being allocated. This can easily result
in a valid job not being possible to run. Note that setting the
max_cpus parameter requires the "scontrol update jobid=# numcpus=#-#"
command be explicitly executed as the option is not available at
job submit time, so it isn't something likely to happen on a
production system. Also note this bug exists in the cons_res plugin
and was just copied to cons_tres.

When one asks for an inactive feature and also specifies the node with -w flag,
the node will be rebooted despite it may contain running jobs.

bug4821

Return resource array structure rather than just CPU count

and avoid race condition calling task before proctrack can introduce.

Bug 5319

to work correctly.

Bug 5155
Bug 4516

delayed until the first job completes execution and it's burst buffer
stage-out is completed.

Bug 4675

If MailProg is not configured and "/bin/mail" (the default) does
not exist, but "/usr/bin/mail" does exist then use "/usr/bin/mail"
as a default value.

Rather than eliminating cores in order across sockets, try to
remove cores evenly across the sockets in order to preserve
access to sockets which might have GPUs we want to use.

Bug 5191

Bug 5159.

This will clear unusable cores from the bitmap as needed.

Coverity CID 186635 and 186636
(same leak, two paths to the same place)

Rather than calling select_g_job_test() multiple times as nodes are
added for consideration by weight, put the node weight into a new
sched_weight field in struct node_record and call select_g_job_test()
once. Let it select the best resources, accumulating resources by
increasing node weight.

MUNGE plugin is no longer packaged separate after the slurm.spec overhaul.

bug 5185

Enhancements to commit 35a13703
bug 5185

Enhancements to commit 35a13703
bug 5185

Previously the function was only testing against the first partition in
the job_record. Now it detects if the job request is multi partition and
if so then loops through all of them until the job will run in any or
until the end of the list, returning the error code from the last one if
the job won't run in any partition.

Bug 5185

This can happen if burst buffer logic is broken

When requesting specific jobids with sacct, the starttime of the request
is 0, which will cause the time range to be outside of the
MaxQueryTimeRange range -- if specified. When requesting specific
jobids, sacct should be able to find the job whenever it started --
unless confined to a smaller range with -S and/or -E.

Bug 5009

For heterogeneous job component with required nodes, explicitly exclude
    those nodes from all other job components.