Fix possible reference of unset bitmap
Fix some logic problems related to non-socket bound GRES

This has never been officially documented, and we would rather
see sites use preempt/qos instead.

Bug 5628.

bug 5629

New --gpu options in the commands and some configuration file changes

Coverity CID 187783

Previously when a job was resized to zero and its
resources moved to another job (--depend=expand)
nothing ran epilog on its nodes to kill processes
and otherwise clean up the allocation. This commit
adds that logic

This avoids a double node allocation as commit 9b55a09b
moves the logic to a common location, removing the need for it
to be specifically in the cons_tres plugin

Bug 5619

Tim approved

Bug 5618

Throw away all but the NEWS entry.

Development continues on the master branch for 19.05, but the
snapshot here should not be used and is thus being removed.

Remove the commented-out documentation as well.

This error occurs when one job is used to expand the allocation of
another job. The node record's "run_job_cnt" is decremented when
the dependent job's epilog completes and the job getting those
resources never has the "run_job_cnt" updated for it, which later
results in the "comp_job_cnt" underflow when it ends. This bug
was discovered in the course of select/cons_tres development,
but impacts all select plugins.

when a batch job gets resized to 0 nodes, it instantly gets killed,
leaving resize scripts around. Also on a Cray system, the resize
can not happen while the job step NHC is still active. This patch
fixes both issues

Coverity CID 187784 and 187785

Coverity CID 187782

# Conflicts:
#	NEWS

Bug 5608

Tim approved

If the dbd comes up after a job array has been submitted to the
controller, the controller calls _update_job_tres() which calls
assoc_mgr_set_tres_cnt_array() which allocates memory for the job's
tres_alloc_cnt. The job array gets scheduled, but job_array_split()
doesn't NULL out the pending job's tres_alloc_cnt, so both the array
task and the pending array job are pointing to the same memory. The
array task calls job_set_alloc_tres() which free's the running job's
tres_alloc_cnt and now the pending array job is pointing to bad memory
and when the array splits again the new array task tries to free
tres_alloc_cnt in job_set_alloc_tres() and segfaults.

Bug 5604

Update slurm.spec and slurm.spec-legacy as well.

This will need to be revisited perhaps link to libslurmfull.so instead
since we will need symbols not exported.

See bug 5605

The previous commit causes erroneous errors to be printed.

test2.14 was made a victim of it.

# Conflicts:
#	src/plugins/jobacct_gather/common/common_jag.c

Bug 5561.

Bug 5538

Bug 5538

This will be handled further in bug 5602

Continuation of 27bf7328