Parent CSM should resolve sibling init order (if partials or similar)

[dehann]

Current CSM states 8o.ii, 8o.iii, and 8o.iv require siblings directly request each other's status. That is not according to tree edges, and can therefore likely only occur in the parent (if following structure).

Stems from

• CSM init endless cycle MWE fail case  #754,
• Consolidate btnd.solvableDims into LikelihoodMessage #910

Also see pull model,

• CSM message passing push or pull model #674

cc @Affie

[dehann]

see xref #955 for relevant code in src/CSM_SiblDwnInit_fetch.jl

[dehann]

Previously (old fetch CSM model) in cascade tree-init, when siblings cannot resolve their initialization there is a problem of figuring out which sibling should be initialized first. The old fetch code required each clique to resolve the init priority of all its siblings (basically sharing data not along edges of the tree -- really bad).

If cascading and sibling order is required again, these old functions should be performed by the common parent instead and then direct which child to solve first.

[dehann]

I believe this issue was closed with new CSM and X stroke. Cascading might come back later.