Type is required for cray persistent burst buffer creation

cray/busrt_buffer - Fix for double counting of used_space at slurmctld
    startup.
bug 3222

Add the POLLRDHUP hack used elsewhere to work around non-standard flag use.

Bug 3227.

cray/busrt_buffer - If total_space in a pool decreases, reset used_space
    rather than trying to account for buffer allocations in progress.
bug 3222

bug 3188

If a cluster was removed from a federation, then the cluster's send was
left around.

salloc/sbatch -w node0 -n2 to allocate 2 nodes instead of only 1 if it
could.

This makes the code look like it does in srun which does do the correct
thing.

The core_resrcs ptr was being dropped on the floor because
unpack_job_resources() allocates its own job_resources_t ptr.

the step table yet, so this patch is invalid.

a job could be accounted for more than it should in the _decay_thread
inside the priority/multifactor plugin.  Before the end_time_exp wasn't
stored for the job which was what was used to determine if the job was
already processed or not.  In 16.05 we were able to fix this mostly, but
for the TRES numbers they could get accounted for multiple times.  Since
a pack was needed to fix this we had to wait until 17.02.

more time than should be allowed would be accounted for.

This only happened on jobs in the completing state when the slurmctld
was shutdown.

This will also be enhanced in 17.02 as the job's end_time_exp is not
stored which is needed to determine if the job has already been through
the decay_thread at end of job.

Bug 3162

bug 3139

# Conflicts:
#	META

issue with gang scheduling.

Bug 3211

MAX_BUF_SIZE is a uint32_t so comparing size (int) to it didn't make
sense.

Unhook it from the build, and remove relevant section from
slurm.spec file as well.

Federated submissions

e.g.
allocation failure: Unspecified error

get_next_job_id() was returning a local id and then the fed_mgr was
turning that into a fed job id. This was a problem because
get_next_job_id() couldn't check to see if an existing job already had
the fed job id. It was only checking for the local job id. This was
exposed in tests that did a reconfigure and the reconfigure loaded in a
old job_id_sequence so that the next job got an id that was already
being used.

The logic to talk to the correct compute nodes still needs to be
implemented. It will come at a later date.

Will submit using federation submission logic. Scheduling logic to come.

to make sure job ptr is accessed within locks.