Uninitialized variables resulted in error of
"cons_res: sync loop not progressing, holding job #"

The most notable problem case is on a cray where a job step
specifically requests one or more node that are not the first
nodes in the job allocation

The problem we have observed is the backfill scheduler temporarily
gives up its locks (one second), but then reclaims them before the
backlog of work completes, basically keeping the backfill scheduler
running for a really long time when under a heavy load.
bug 297

Fix minor bug in sdiag backfill scheduling time reported on Bluegene systems
Improve explanation of backfill scheduling cycle time calculation.

Defers (rather than forgets) reboot request with job running on the
node within a reservation.

all preemptable jobs on the midplane instead of just the ones it needed to.

This bug was introduced in commit f1cf6d2d
fix for bug 290

Downing the node will kill all jobs allocated to the node, very bad
on something like a BlueGene system

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.

the node tab and we didn't notice.

Response to bug 274

Make test work if current working directory not in the search path
Check for appropriate task rank on POE based systems
Disable the entire test on POE systems

Without this change pmdv12 was bound to one CPU and could not use
all of the resources allocated to the job step for the tasks that
it launches

This only changes behaviour when the --ntasks option is not used,
but the --cpus-per-task option is use

we used cpus erroneously but now we use tasks.  The cpus variable will
be taken out in 2.6.