ex. squeue -M<cluster> was talking to the local cluster instead of
<clsuter>.
Continuation of 418e1c69

Continuation of add1f9d3. Had calls to fed_mgr_is_active() in another
branch.

END_TIMER was being called without a START_TIMER.
Coverity CID:165991

ACTIVE: accepts submissions and schedules
INACTIVE: doesn't accept submissions or schedules
DRAIN: schedules but doesn't accept submissions
DRAIN+REMOVE: like DRAIN but cluster removes itself from federation once
all federation jobs are gone.

Continuation of f9d132fc which just stopped the back_scheduler from
starting up. This patch allows the backfill scheduler to be stopped
after starting.

Clearing should make the job eligible on all clusters again.

cluster for it to handle the request.

for ClusterFeatures.

e.g.
scontrol update <jobid> clusters=fed1,fed2

Currently assumes that if the origin job updates successfully then it
can submit the job to the siblings. Will need to expand on this to
handle heterogenous setups.

with the correct node select plugin_id. The dbd stores the plugins
actual plugin id but the plugin_id doesn't index you into the
plugin_context array. So it needs to be translated to the index so that
the correct node_select plugin accessed properly.

If the pointer is NULL then the size_val should be zero or you'll be
packing garbage.

Compare the release locks to the acquired locks.

More interestingly, in further commits this will allow us to annotate
functions to verify the appropriate locks are held at runtime, and
head off potential sources of corruption.

Only enabled on development builds.

Calling lock_slurmctld() while already holding locks leads to deadlock.
Intentionally cause such instances to abort() on development builds to
force these locations to the surface.

when using fed_mgr_is_active(). It should only be used outside of any
locks.

Prior security check only permitted root or the SlurmUser to update.

No way to do this through sbatch, but the API would permit it.

Bug 3631.