When using consecutive steps, it appears that in some cases, the time required
by the slurmstepd on the execution nodes to inform the controler of the completion
of the step is higher than the time required to request the following step.
In that scenario, the controler can reject the step by returning the error code
ESLURM_REQUESTED_NODE_CONFIG_UNAVAILABLE even if the step could be executed if
all the former steps were correctly finished.

This can be reproduced by launching consecutive steps and introducing dalys in
the spank epilog on the execution nodes.

The behavior is changed to only defer the execution of the step by returning
ESLURM_NODES_BUSY when all the available nodes are not idle considering the
former steps.

slurmctld restart.

allocation.

NOTE: If you were setting the environment variable SLURMSTEPD_OOM_ADJ=-17,
it should be set to -1000 for Linux 2.6.36 kernel or later.

specifying the number of tasks and not the number of nodes.

On job kill requeust, send SIGCONT, SIGTERM, wait KillWait and send
SIGKILL. Previously just sent SIGKILL to tasks.

Incorrect error codes returned in some cases, especially if the slurmdbd is down

Previously for linux systems all information was placed on a single line.

interface instead of through the normal method.

for passthrough gets removed on a dynamic system.

in error for passthrough.

user's pending allocation was started with srun and then for some reason
the slurmctld was brought down and while it was down the srun was removed.

previously it overwrote the poll_thread id

This is needed for when a free request is added to a block but there are
jobs finishing up so we don't start new jobs on the block since they will
fail on start.

Previously the node count would change from c-node count to midplane count
(but still be interpreted as a c-node count).