This is for consistency. All of the other backfill parameters
start with "bf_".

Conflicts:
	NEWS
	src/slurmd/slurmd/req.c

Add support for SchedulerParameters value of bf_max_job_start that limits
the total number of jobs that can be started in a single iteration of the
backfill scheduler.
bug 607

A test for bf_max_job_user was > rather than >=

the correct lib.

Since the QOS priority is 32-bits, base the preemption priority
upon that 32-bit field and ignore the job size.
Variant of commit  a3e74ef2

completes

This avoids some misleading error message

The job preemption order was based upon the lowest 16 bits of a
QOS priority, but the field holds 32 bits. This uses a value of
0xffff if the QOS priority is higher.

If the slurm.conf changes to remove nodes from a job step in the
process of running Node Health Check, the step record would be
purged. Then when the NHC completes, it's step record pointer
would be invalid.
The change here will prevent such a job step record from being
purged.
This was found while investigating bug 612, but would be a very
unusual condition and does not fix this bug.

always be set to SLURM_SUCCESS since it isn't used before.

If the switch/cray global state save/restore fails, avoid re-allocating
ports based upon the job steps that we can recover

Previously slurmctld would restart without information about
allocated ports. This add save/restore logic which will work
for graceful shutdowns. More work is needed in the case of
slurmctld crashes.

The merge from v2.6 to master in commit 18985643
seems to have gone horribly wrong. This should fix it.

bug 607

bug 607

Make job array expressions more flexible to accept multiple step counts in
the expression (e.g. "--array=1-10:2,50-60:5,123").

If a partition was configured with Shared=yes, then submitting a
job with --core-spec option failed to allocate the node exclusively
to that job.

No changes in logic