This corrects a bug introduced in commit 952401ec
The NODE_CR_RESV value is being stored in a job as an 8-bit variable, so we
can not use a value of 10000 for an exclusive node allocation. It's value was
reduced to 250, which will be the maximum number of jobs that can be run on any
node. Problem demonstrated by "salloc -N1 --exclusive" allocating the job only
one CPU on the node rather than all CPUs on the node.

Fixing problems with core based reservations and jobs using exclusive flag

'exclusive' flag

Conflicts:
	src/api/reservation_info.c
	src/common/node_select.c
	src/common/node_select.h
	src/plugins/sched/backfill/backfill.c
	src/plugins/sched/builtin/builtin.c
	src/plugins/sched/wiki2/job_will_run.c
	src/plugins/select/bluegene/select_bluegene.c
	src/plugins/select/cons_res/dist_tasks.c
	src/plugins/select/cons_res/job_test.c
	src/plugins/select/cons_res/select_cons_res.c
	src/plugins/select/cray/other_select.c
	src/plugins/select/cray/other_select.h
	src/plugins/select/cray/select_cray.c
	src/plugins/select/linear/select_linear.c
	src/scontrol/create_res.c
	src/slurmctld/job_scheduler.c
	src/slurmctld/node_scheduler.c
	src/slurmctld/reservation.c
	src/slurmctld/reservation.h
	src/slurmctld/slurmctld.h

This corresponds to commit dd2dce54
from Mark Grondona's work in squeue, but applied to the sview command.

Slurm 2.4 minor fixes

Batch job will have environment variable set: "SLURM_CPU_FREQ_REQ=0"
and this will be loaded and reported as an invalid value by srun.

This addresses trouble ticket 85

runjob_mux

is always set when sending or receiving a message.

Set SLURM_CONF in default prolog/epilog environment instead
of only in spank prolog/epilog environment.

This change fixes a potential hang during spank prolog/epilog
execution due to the possibility of memory allocation after
fork(2) and before exec(2) when invoking slurmstepd spank
prolog|epilog.

This also has the benefit that SLURM commands used in prolog and epilog
scripts will use the correct slurm.conf file.

If exec_wait_child_wait_for_parent() fails for any reason, it is safer
to abort immediately rather than proceed to execute the user's job.

On a failure of fork(2), slurmstepd would print an error and exit,
possibly leaving previously forked children waiting.

Ensure a better cleanup by killing all active children on fork failure
before exiting slurmstepd.

Close the read end of the pipe slurmstepd uses to notify children
it is time to call exec(2) in order to save one file descriptor per
task. (Previously, the read side of the pipe wasn't closed until
exec_wait_info was destroyed)

For some reason squeue was treating completing jobs the same as
pending jobs, and reported the number of nodes as the maximum of
requested nodelist, requested node count or CPUs (divided into nodes?)

This is in contrast to the squeue manpage which explicitly states
that the number of nodes reported for completing jobs should
be only the nodes that are still allocated to the job.

This patch removes the special handling of completing jobs in
src/squeue/print.c:_get_node_cnt(), so that the squeue output for
completing jobs matches documentation. A comment is also added
so that developers looking at the code understand what is going on.

Conflicts:
	doc/html/high_throughput.shtml