Before fixing fed.flags to be initialized to FEDERATION_NOT_SET, the
federation's flags were being set to 0 when a federation modification
happened.  These tests verify that the flags stay after a federation
modification.

Was modeled after cluster adding where commit the check was being done
before sending the changes to the dbd. But since the dbd isn't making
any additional tables for federations -- like it does for clusters -- it
can send to the dbd first and make sure they worked and then ask to
commit the changes.

Ran into the issue after initializing fed flags to NOTSET. Fed flags
were always being set to 0 on modification.

Changed READ_LOCK to WRITE_LOCK since we are updating the node's select
info (select_g_select_nodeinfo_set_all).

Inside locks.

Also fixes setting weight at cluster creation.

Don't store local cluster info in siblings. Store separately for
state_save and "scontrol show fed".

This is required in order to make sure that a compute node reboots as
requested; even if the slurmctld daemon restarts. Previously if the
slurmctld daemon restarted, we couldn't tell if the compute node
rebooted before or after the request.
This commit expands upon the work of commit 4517c454
by adding the reboot request time to the node record, which is
saved and restored by slurmctld.
bug 3042

Handle case when slurmctld daemon restart while compute node reboot in
    progress. Return node to service rather than setting DOWN.
bug 3042

Add salloc_wait_nodes option to the SchedulerParameters parameter in the
    slurm.conf file controlling when the salloc command returns in relation to
    when nodes are ready for use (i.e. booted).
bug 3043

bug 3055

bug 3054

before all was moved into a common location in common.c.

reservations.

sched/backfill - Check that a user's QOS is allowed to use a partition
    before trying to schedule resources on that partition for the job.
bug 3039

bug 3037

Conflicts:
	src/plugins/burst_buffer/common/burst_buffer_common.h

bug 3035 and 3009