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.

functions.

slurm_protocol_api