dealing with returns from _validate_tres_usage_limits_for_qos and
_validate_tres_usage_limits_for_assoc an enum

_validate_tres_usage_limits_for_assoc an enum (tres_usage_t)

Collapse begin_job_resv_check and fini_job_resv_check into
job_resv_check, and call directly from controller.c rather than
including in job_time_limit.

Introduced by commit 059275f6 when the timer is trigger.
Releasing the locks means that job_ptr may point to an element that was
deleted by a different thread in the meantime. Restructuring the code
to advance the iterator prevents this - the iterator itself does not have
this issue as the List structure will manage the position during the
sleep().

While here, move the reservation update handling outside of this
loop to simplify operation. This does not need to piggy-back on the
scan of the job_list - switching to using list_for_each should
mitigate some of the performance loss by needing a second full pass.

Bug 3414.

# Conflicts:
#	RELEASE_NOTES

These were mis-calculated previously, and are internal implementation details
that weren't meant to be exposed.

association GrpWall limit.

limits.

Bug 3476

Bug 3476

old ones.

This is cosmetic only, no code change.

Bug 3476

When an interactive allocation request comes to a controller it fills in
the job's resp_host from the incoming addr. The controller then uses the
resp_host and the alloc_resp_port, sent from srun/salloc, to respond to
listening srun/salloc. In a federation, the origin cluster needs to pass
the initial resp_host from the origin cluster to the siblings. Otherwise
the siblings set the resp_host to the host of the origin cluster and the
sibling clusters won't be able to contact the listening srun/salloc.

Continuation of 0098c0c0 -- which removed the ability submit a
batch step within an existing allocation. Removing test15.17 since the
functionality was removed. This is undocumented behavior and says it was
for LSF which isn't supported. There is also the problem where if you
submit two batch steps in an exsiting allocation that the job will be
killed and the node drained because the slurmd will see duplicate
jobids.

Conflicts:
	src/common/slurmdbd_defs.c

Checked for suffix of "k" and "k" (not "K").
Same problem with suffic of "m".

Missed a sanity check.

to have a buffer to fill in.

Fix federated will runs so that the the same federated job id is being
used on each cluster when a willrun is being done. Also fix it so that a
federated will run will check start times of existing jobs.

Bug 3472

regcomp() is not safe to use across a fork in older glibc versions.
Reinitialize the keyvalue_re structure after the fork through an atfork()
handler.

Bug 3276.

The problem was that the fed_mgr sets the jobid before the jobid is
validated so that the jobid can be the same when submitting to all
siblings. _validate_job_desc() validates that only slurm_user or root
can specify jobids. Now in a federation, _validate_job_desc() doesn't
need to validate the jobid since specifying a specific jobid is disabled
in federations.

Since a federation determines where the job originated from by looking
at the job's id, the user would have to give a jobid that matches the
origin cluster. Another other option would be to submit jobid specified
jobs as non-federated jobs. But for now this is being disabled.