Timing changes due to faster job step launch

This can be especially useful to schedule GPUs. For example a node can be
associated with two Slurm partitions (e.g. "cpu" and "gpu") and the
partition/queue "cpu" could be limited to only a subset of the node's CPUs,
insuring that one or more CPUs would be available to jobs in the "gpu"
partition/queue.

This happens when a job has multiple partitions and
priority/multifactor is NOT in use

fix of the following problem:
if a node is excised from a job and a reconfiguration(e.g., update
partition) is done when the job is still running, the node will be left
in state idle but not available any more until the next
reconfiguration/restart of slurmctld after the job finished.

to be edited more.

to be running in the calling program.

the node tab and we didn't notice.

which reads the array boundary.

the daemon to core dump.

Response to bug 274