to gain the correct limit when a parent account is root and you
remove a subaccount's limit which exists on the parent account.

Expect is sometimes splitting lines on long output bufffers
  resulting in this test to sporatically fail. This reduces
  the volume of output, which seems to fix the problem

This fixes changes made in commit d4d51de7
Which fails for a job state of Pending (needed to special case the zero value).

abort if specified acct_gather_energy plugin can not be loaded
  rather than deadlocking
bug 1797

NOTE: SLURMCTLD WILL NOT COMPILE WITH THIS COMMIT!

the mysql plugin and sacctmgr should though

instead of it's own.

limits so it is easier to change/add/remove any limit.

Conflicts:
	src/slurmctld/job_mgr.c

Under some conditions if an attempt to schedule the last task of
  a job array (the meta-record of the job array) fails, it's
  task ID will be changed from the appropriate value to NO_VAL.
bug 1790

Bug 1770

Revert modification that would NOT count pthreads that are being
  throttled against the slurmctld limit. Harvard reported that
  slurmctld would spawn so many pthreads that it failed. In
  extreme environments, the slurmctld could spawn tens of
  thousands of pthreads with the modified logic.

Conflicts:
	doc/man/man1/squeue.1
	src/common/slurm_protocol_defs.c

Conflicts:
	src/common/slurm_step_layout.c
	src/plugins/select/cons_res/job_test.c
	src/plugins/select/cons_res/job_test.h
	src/plugins/select/cons_res/select_cons_res.c
	src/srun/libsrun/opt.c

Bug 1798

If a job can only be started by preempting other jobs, the old logic
  could report the error:
  "cons_res: sync loop not progressing, holding job #"
  due to the usable CPUs and GRES needed by the pending job not
  matching. This change prevents the error message and job hold
  when job preemption logic is being used. The error message and
  job hold still take place for job scheduling outside of preemption,
  which will match CPUs and GRES at the beginning.
bug 1750

Under some conditions the select/cons_res plugin will hold a job,
  setting it's priority to zero and reason to HELD. The logic in
  slurmctld's main scheduling loop previously kept its priority
  at zero, but changed the reason from HELD to RESOURCES. This
  change leaves the proper job state as set by the select plugin.
This may be related to bug 1750

The backfill scheduler will periodically release locks for other
  actions. If a job is held during the time that locks were released,
  that job might still have been scheduled by the backfill scheduler
  (i.e. it failed to check for a job with a priority of zero).
could be a root cause for bug 1750

Conflicts:
	src/slurmctld/job_mgr.c

Previous logic could fail to update some tasks of a job array for
  some fields.
bug 1777