If a job allocation returns some invalid contents, the pointer
  to the job structure may be NULL. This change preserves the error
  message and avoids a segv.

Fix case where if the backup slurmdbd has existing connections when it gives up control that the it would be killed.

If the backup had existing connections when giving up control, it would try to
signal the existing threads by using pthread_kill to send SIGKILL to the
threads. The problem is that SIGKILL doesn't go the thread but the main process
and the backup dbd would be killed.

when a cold-start (-c) happens to the slurmctld.

Conflicts:
	src/sacct/options.c

from a user.

This would cause the slurmctld to cache the old default which wasn't valid
and cause the user to have to request the association always.

Conflicts:
	NEWS
	src/plugins/accounting_storage/mysql/as_mysql_job.c

bug 2009

Each node could have fewer tasks allocated on a node than the plane
  size, which broke the test. The plane size needs to be treated
  as a maximum consecutive rank value.

byg 2013

database but the start record hadn't made it yet.

Create a "task" cgroup at job allocation time via the prolog container.
  A dummy "sleep" process will occupy the cgroup so long as the job exits.
bug 1994

requirements.

Add acct_gather_energy/ibmaem plugin for systems with IBM Systems Director
    Active Energy Manager.

Conflicts:
	src/slurmctld/job_mgr.c

bug 2011

It would not cause any problem other than excess memory being
allocated, but was found by CLANG.

','.

Conflicts:
	src/common/proc_args.c

bug 1999

A configuration of "DefMemPerNode=UNLIMITED" prevented more than
one job from running at a time on a given node, which broke some
tests. These changes prevent the tests from breaking.

Conflicts:
	NEWS

Don't requeue RPC going out from slurmctld to DOWN nodes (can generate
    repeating communication errors).
bug 2002

This will only happen if a PING RPC for the node is already queued
  when the decision is made to power it down, then fails to get
  a response for the ping (since the node is already down).
bug 1995

If a job's CPUs/task ratio is increased due to configured MaxMemPerCPU,
then increase it's allocated CPU count in order to enforce CPU limits.
Previous logic would increase/set the cpus_per_task as needed if a
job's --mem-per-cpu was above the configured MaxMemPerCPU, but NOT
increase the min_cpus or max_cpus varilable. This resulted in allocating
the wrong CPU count.

This will only happen if a PING RPC for the node is already queued
  when the decision is made to power it down, then fails to get
  a response for the ping (since the node is already down).
bug 1995