Note that this does not protect against all possible problems here.
The setgroups() call in Linux at least is willing to set any gid_t
value except -1 on a group, so calls will not always fail on corrupted
group lists.

Bug 3320.

Remove uncached _get_grouplist() call which was only used here.

Bug 3315.

test12.2 was consistently failing on smd# cluster with tiny differences
  in the disk read and written. This change permits those tiny discrepancies
  to exist without failing the test.
  Here are the numbers, which are consistent:

  sacct --noheader -p --job=763.0 --format MaxDiskWrite,AveDiskWrite,MaxDiskRead,AveDiskRead
  10.00M|10.00M|10.03M|10.03M|
  (i.e. 0.3% discrepancy, up to 0.5% allowed with current code)

Test was failing due to hitting the memory limit (at least on smd1).

There were already several configurations that could cause this test
  to fail. I just added another.

Fix parsing in regression test1.92 for some prompts.
bug 2792

Recognize a KNL's proper NUMA count (rather than setting it to the value
    in slurm.conf) when using FastSchedule=0. Previous logic would change
    the NUMA count on the node to match what was in slurm.conf, which would
    mess up task layout with respect to the sockets.
bug 3306

HWLOC is required to properly determine topology

from the slurm.conf when using FastSchedule=0.

cray/burst_buffer - If slurmctld daemon restarts with pending job and burst
    buffer having unknown file stage-in status, teardown the buffer, defer the
    job, and start stage-in over again.
bug 3295

Add more detail to log message and change from error to debug2
  with an explanation of how this happens

bug 3314

limits after the node selection to make sure it doesn't violate those limits
and if it does change the reason for waiting so we don't reserve resources
on jobs violating accounting limits.

Bug 3029

Bug 3301.

node_features/knl_cray - Fix possible race condition when changing node
    state that could result in old KNL mode as an active features.
bug 3235

No change in logic

cray/burst_buffer - Increase time to synchronize operations between threads
    from 5 to 60 seconds ("setup" operation time observed over 17 seconds).
    This should fix a race condition between a thread performing a buffer
    creation (setup) and a thread looking for unexpected buffers. If a
    buffer is found during the time window allowed for creation, it's
    space will be counted twice. First by the status checking thread
    and second by the thread doing the creation. The deallocation only
    happens once, so the used space information can be left with an
    invalid value.
bug 3295

Never used and is uninitialized making backtraces more confusing.
Fix whitespace in bcast_parameters struct while here.

No functional change.

static variable means multiple active decompression streams will corrupt
zlib's internal state, which can lead to a segfault.

Bug 3299.

On a reconfig, the exc_node_bitmap is cleared but then it was
not built again since last_work_scan was declared as a local static
variable in _do_power_work(). The fix is to make it global within the
plugin and reinitialize it to 0 on _init_power_config().

Bug 3078.

Bug 3267.

Termination can race against step creation if, e.g., ill-behaved SPANK plugins
are in use.

Bug 3248.

sched/backfill plugin: Make malloc match data type (defined as uint32_t and
    allocated as int). No failures observed, if type "int" is smaller than
    "uint32_t", it could result in an invalid memory reference.

Fix API call: slurm_job_cpus_allocated_str_on_node_id() and
in turn slurm_job_cpus_allocated_str_on_node() to return correct
results for anything but first node. This was caused by missed logic
to calculate fist bit belongs to particular node. Lookup was always
starting from bit 0.

Bug 3266.

After one second of wall time, simulate the termination of all remaining
   running jobs in order to respond in a reasonable time frame.
bug 3275

Modify backfill algorithm to improve performance with large numbers of
    running jobs. Group running jobs that end in a "similar" time frame using a
    time window that grows exponentially rather than linearly. The original
    window sizes were (in units of minutes):
    0, 1, 2, 3, 4, 5, 6, 7, ... minutes
    The new window sizes are:
    0.5, 1, 2, 4, 8, 16, 32, ... minutes
    This can dramatically reduce the number of instances where the very time
    consuming "can the pending job run now" operation is executed, especailly
    if there are 1000+ running jobs.
bug 3275