Continuation of 1f831f33

Conflicts:
	src/slurmctld/reservation.c

This is a change in logic from commit 00099596
The original commit corrected the logic from CPU to core count, but
used the cores_per_socket count rather than computing the total
core count (cores_per_socket * sockets).
bug 1830

Continuation of 1bf2d7b9

Correct RebootProgram logic when executed outside of a maintenance
  reservation. Previous logic would mark the node up upon response
  to the reboot RPC (from slurmctld to slurmc) and when the node
  actually rebooted, flag that as an unexpected reboot. This new
  logic checks the node's up time to not mark the compute node as
  being usable until the reboot actually takes place.
but 1866

For testing purposes, add a slurmd flag so that it appears the
compute node has rebooted whenever slurmd restarts.

Don't load in PriorityWeightTRES

bug 1600, additions

Add environment variables SLURM_ARRAY_TASK_MAX, SLURM_ARRAY_TASK_MIN,
SLURM_ARRAY_TASK_STEP for job arrays.
bug 1600

to free it otherwise.

198aa220

Save state, even when no buffers are allocated.
Set "last_update_time" on the buffer in some places where it was missing.
Make sure we save state at shutdown.

Bug 1826

since this should never happen unless we don't have state files.

association manager.

In pam_setup, correct comments for typos and to match the code.  On failure,
properly deallocate the PAM resources and ensure the PAM handle is null so as
to make calling pam_finish always safe.

In pam_finish, always try to deallocate all the PAM resources.  Also, ensure
the PAM handle is null so as to make calling pam_finish always safe.  This
allows for calling pam_finish multiple times without error.

This adds a simple test for persistent burst buffer creation and
  deletion for the burst_buffer/cray plugin.

Remove "is_job_array" argument to bb_g_job_validate2() function.
Defer starting job that needs persistent burst buffer until it has been created.
Avoid trying to create persistent burst buffer with duplicate name

This will be needed for TRES limit enforcement

This is a more thorough treatment of bug 1790 and commit
  d2545ca746ea0a2f9653664a601052cfd5eb8ad
  It clears the task_id_bitmap once the last task is scheduled
  and task_cnt becomes zero

Prevent job array task ID from being reported as NO_VAL if last task in the
  array gets requeued. The problem is that when that task starts, the task
  bitmap entry for it stays set, but the task counter gets decremented.
  If that job then gets requeued, under some conditions a failure to schedule
  it results in the array_task_id in the job record getting set to NO_VAL.
  Then when building the job info to report for squeue/scontrol, the string
  showing the pending task ID's is not rebuilt due to that counter being
  zero. All indications are that the job runs fine, only the information
  reported to squeue/scontrol is wrong.
bug 1790