The problem only exists on a subset of KNL models, those with 68 cores.
bug 2941

And make it a pointer on the job_record struct.

Lost after rebase.

- Only ask if cluster is being assigned to a different federation.
- Show that cluster is already part of federation and don't add cluster to
list of updates.
- Don't send updates if nothing to change (after finding that clusters are
already part of federations).

New jobs will get job IDs within the new range. Even though the
pre-existing large jobid-jobs will have federated jobids, they will be
treated as local jobs.

Fix by allocating slurm_msg_ts and freeing instead of using local
variables.

Display local cluster first and don't show persistconn.
$ scontrol show fed
Federation: f1
Self:       fed1:127.0.0.1:31002 ID:1 FedState:ACTIVE Weight:0
Sibling:    fed2:127.0.0.1:32002 ID:2 FedState:ACTIVE Weight:0 PersistConn:Connected
Sibling:    fed3:127.0.0.1:33002 ID:3 FedState:ACTIVE Weight:0 PersistConn:Connected

Appends federation related columns to default format options.

Add ACTIVE and INACTIVE states.
Handle transistions of states
ex.
When cluster is added - should get NA
Added to a federation - should get ACTIVE
Moved to same federation - should keep existing state
Moved to another federation - should get ACTIVE
Removed from federation - should get NA

An exit code should trump other conditions and exit fast.

Wouldn't exit with non-zero if match tests failed.

dump_update_list isn't currently called, but for completeness print what
SLURMDB_UPDATE_FEDS is in case it does it called.

Verify that cluster is removed from federation when cluser is deleted.
Verify federation is removed from clusters when federation is deleted.