For unit testing

by assignment of a value to the out_tres_limit_array (the 3rd
argument to the _validate_tres_usage_limits_for_qos function),
I added function _validate_tres_usage_limits with an added
bool argument to check whether the assignment should be made.
_validate_tres_usage_limits_for_{assoc,qos} just calls/returns
_validate_tres_usage_limits with the new bool argument being set for
expected functionality:

out_tres_limit_set == true  same as _validate_tres_usage_limits_for_qos
out_tres_limit_set == false same as
_validate_tres_usage_limits_for_assoc

I went with the call through approach instead of changing the existing
called function names; not knowing if future developments would warrant
the functions diverging further, and so keeping differing function
names a necessity.

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