Avoid including unused CPUs in a job's allocation when cores or sockets are
allocated. A minor variation of this has been tested with version 14.11, but
I do not want to risk introducing a problem with this new logic.
bug 1212

Conflicts:
	src/slurmd/slurmd/req.c

Do not requeue a batch job from slurmd daemon if it is killed while in
the process of being launched (a race condition introduced in v14.03.9).
This partially reverts commit 2bc9bc29

CR_CORE/SOCKET system lay out tasks correctly.

This is a complete fix for bug 1247

You can also reference commit 7461c119 for tests to give correct
functionality.

Conflicts:
	src/common/pack.c

This reverts commit bc7ea952.

This ended up causing more issues than it solved, reverting.

Unless sbatch submits a job to multiple clusters, do not bother
to commuicate with slurmdbd

15.08, but this keeps track of allocated cpus as well as usable cpus:
meaning if a user requests --hint=nomultithread they are allocated cpus
that aren't usable since they requested to only use the 1st thread on
each core.

reference bug 1247

with CR_PACK_NODES.

Really do commit d388dd67 a different way to get the same info and
be able to lay out tasks correctly when --hint=nomultithread.

tests on a 4 core 8 thread system are
srun -n6 --hint=nomultithread --exclusive whereami | sort -h
srun: cpu count 6
   0 snowflake0 - MASK:0x1
   1 snowflake0 - MASK:0x2
   2 snowflake0 - MASK:0x4
   3 snowflake0 - MASK:0x8
   4 snowflake1 - MASK:0x1
   5 snowflake1 - MASK:0x2

and

srun -n10 -N5 --hint=nomultithread --exclusive whereami | sort -h
srun: cpu count 10
   0 snowflake0 - MASK:0x1
   1 snowflake0 - MASK:0x2
   2 snowflake0 - MASK:0x4
   3 snowflake0 - MASK:0x8
   4 snowflake1 - MASK:0x1
   5 snowflake1 - MASK:0x2
   6 snowflake1 - MASK:0x4
   7 snowflake2 - MASK:0x1
   8 snowflake3 - MASK:0x1
   9 snowflake4 - MASK:0x1

Move will-run test for multiple clusters from the sbatch code into the API
so that it can be used with DRMAA.

especially when in memory debug mode

helgrind found the locks here were being make in reverse order
after the initial locks at the top of the function.

This reverts commit a7ad186e0f2b643c4e2bf302bc18e892d499cd4a.

helgrind found that the locks were taken in reverse order in some
places. This makes the ordering of locks consistent.

    an maintenance reservation that is not active yet.

This should result in better performance

problem with brackets and left unused variable

These changes do not effect operation, but eliminate some false
positive errors from helgrind, namely testing some variables values
that are sometimes protected by locks and other times not protected.