In order for scancel -u <user> to be able to cancel jobs by user that
exist only on other clusters in the federation, scancel needs to load
all of them.

Running jobs can happen out of order.

Original list was being free'd before the copy was.

sbatch|srun --test-only
Bug 3740

Bug 3802

Bug 3641

and steps

Bug 3700

Bug 3699

Bug 3698

Bug 3697

Bug 3667

to validate scontrol --local and --sibling options

Bug 3662

Only used in fed_mgr.c

This will make it easier to add new proto types without having to
modifying protocol_defs.[ch].

Leaving job_lock and job_unlock to be handled by slurmctld_req since
they aren't a "queued" type.

prevent possible memory leak.

All handled in _proc_multi_msg except for sib_job_[un]lock.

This prevents deadlocks when having the fed_job_list_mutex locked higher
up and calling job_completion_logger inside of the locked mutex.

Don't need to have the fed_write_lock when destroying the
persist_conn_server.

Since federated submissions are now asynchronous and because the
working_cluster_rec can be multithreaded, it's better to have the
federadated will_runs in the client. This prevents the deadlocks and
holding up the persistent connections as could happen in the previous
model.

With the change to the asynchronous model, it's better to have the
cluster always get the lock from the origin cluster. Previously, the
origin cluster would try to pick one cluster that could start the job
the soonest and the scenario where there would be only one sibling was
more common. Now that sibling jobs are sent to all clusters this is less
common.

Queue up the fed job completions.