when there was only one job_table for all clusters where there was potential
for a job to start on multiple clusters at the same time it was needed to
differentiate one job from another.  Since this hasn't been the case for many
years we are removing it as we really should only need job_id and time_submit
to make it unique.

which will be changing it's unique index in a following commit.

NO_VAL values to NO_VAL64 on it.

Still use the conf pointer, rather than rewriting the following lines,
but set it directly to &slurmctld_conf.

slurm_conf_lock() returns &slurmctld_conf (with added locking).
Avoid the additional function call and refernce the variable directly.

Locking the conf is already handled within slurmctld by lock_slurmctld,
and locations within slurmcltd changing slurmctld_conf don't grab the separate
slurm_conf_lock() mutex anyways.

Don't look it up again; this also removes a call to slurm_conf_lock().

bug 3562, see comment 22

Bug 3577.

other half go to libslurmdb.so.

Turns out in 17.11 if you are using --with-shared-libslurm sacct will link to
both libslurmfull.so and libslurmdb.so.  In the case of linking to the
accounting_storage/slurmdbd plugin it will callback to slurmdbd_defs_init
which would be in libslurmdb.so but the call to acct_storage_p_get_connection
would call slurm_open_slurmdbd_conn which is in libslurmfull.so and it would
xassert on slurmdbd_defs_inited which was set in libslurmdb.so but not in
libslurmfull.so.

So the moral of the story is don't export half a file in one lib and the other
half in a different lib.

Perhaps we should only have 1 lib all together, but that isn't the way it is
done today.  This fixes the issue and has the entire file exported to
libslurmfull.so so we should be good.  But just a note for the future.

This was an unexpected regression caused by commit 5a5347c7.

Bug 3530

NOTE: there does appear to be other issues here, but we didn't fell comfortable
changing this many things in 17.02 for fear of breaking something.

This only fixes a bit of the issue as it appears node_scheduler.c has a fuller
test for these.  In 17.11 I plan to make this a function that will fill in
the min, req, max nodes and use it in both places in the code to prevent this
from happening again.

Code calls list_find_first to search in resv_list whether the requested
name for the new reservation already exists. If it exists, resv_ptr is
set with the pointer to the existing reservation. Then the code goto
bad_parse label and xfreed that resv_ptr, thus corrupting the list data
by freeing the existing reservation. This is fixed by only freeing memory on the
new local resv_ptr instead of always freeing memory.  xfree is also not
sufficient for freeing the memory, we needed to call _del_resv_rec() or we would
leak the memory we had transferred from the resv_desc_ptr.  This also involved
NULLing out the other variables freed after bad_parse, or you would get
double frees.

Bug 3558.

And cleanup code further.

assoc_mgr_make_tres_str_from_array.

array task id.

This is combination with the previous commit.

Bug 3563