at startup.  Starting it up when you get a connection from another
cluster could cause delays in processing the request.

want to only wait for message_timeout instead of forever.  Otherwise
we could hit deadlock if the other person is trying to do the same
thing.

processed at a time.  Otherwise you could get issues if you are
rapidly adding and removing a cluster from a federation.  Probably
not likely in real life, but in testing that is a different story.

slurmctld.

scenario when first added to a federation.

the same logic that was found in the slurmdbd.  Now both functionalities
share the same code.

This was done with the merge right before this commit.

update is sent to a slurmctld.

with real persistent connections.

the fd is set to -1 so we don't try to actually use it.

when querying if there are runaway jobs.

out in, but it is back now!

The old logic isn't needed anymore since we spawn a new thread.

they finish before shutting down.

the dbd.  (or it will treat it as a slurmctld)

reconnected.

a persistent connection.

as they end in the controller.

returning items in the slurmctld.

handled elsewhere now.

slurmctld.