4 billion jobs in your database you will want to update your slurmctld at
the same time as your slurmdbd to prevent roll over of this variable as
it is 32 bit previous versions of Slurm.

mysql_insert_id was always returning a my_ulonglong so we are just
making it more compliant.

This is needed primarily for a following commit that will change the
job db_index to be be 64bit.

Bug 2955.

Document the partition limits considered in the EnforcePartLimits
logic.
bug 2920

Correction to commit b45a55bc
but 2920

Make EnforcePartLimit support logic work with any ordering of partitions
    in job submit request.
Developed jointly with Alejandro Sanchez <alex@schedmd.com>
bug 2920

Copy + paste error, CID 44786.

Calculation switched the node count in place of the cpu count, which
results in incorrect estimates.

CID 44784.

CID 44787.

Mistake was only visible with DEBUG_TIME, and under a debug3 message.

CID 44785.

Bug 2950. Also identified as CID 56684 (copy+paste error).

CID 45023 and 45024.

This now provides a consistent approach to when all partition
priorities become zero. Before 'scontrol update' could leave
norm_prio on the last partition to become zero as one.

Convert _calc_part_tres into a ListForF signature.

Also removes a double xfree of part_ptr->tres_cnt.

Tweak _dump_part_state() to act as a ListForF function.

Fix task:CPU binding logic for some processors. This bug was introduced
in version 16.05.1 to address KNL bunding problem.
bug 2972

Conflicts:
	src/slurmctld/proc_req.c

Needed due to part_filter_set() calls; without write lock this can race
returning inconsistent results to 'sinfo'.

Bug 2958.

Regression test fixes if SelectTypePlugin not managing memory and no node
    memory size set (defaults to 1 MB per node).

Conflicts:
	src/common/slurm_acct_gather_profile.c

Fix race condition in the account_gather plugin that could result in job
    stuck in COMPLETING state.
bug 2973

These problems have been around for a while, but coverity just started
  to report them for some reason.

Prior logic used to create an advanced reservation based upon a core
  count would ignore the specialized cores. Then when a job tried to
  use the reservation, it would consider the specialized cores and
  not be able to use the core count used in the reservation creation.
  This change considers specialized cores when creating the reservation.

There was a line removed that should not have been