[runtime] Formalize `Child` vs `Sibling`

[patrick-ogrady]

Related: #1833
Related: #1666

In the code, we implicitly assume that with_label creates a "child" and clone() creates a "sibling" (sometimes we use clone() as a child when we don't take the time to add a label).

This makes what should be a pretty straightforward supervised abort (in consensus) behave unexpectedly because we call .with_label on some actor's provided context to setup some inner actors (making them a child of the parent rather than the actor).

Current

[application]
    |
  [engine]
    |
  (with_label) -----------------------> [engine_resolver] -> [engine_resolver]:spawn
    |                      |
  [engine]::spawn     [engine_voter]
                           |
                      [engine_voter]::spawn

Implied

[application]
    |
    |
  [engine]::spawn
   |             |
[engine_voter]  [engine_resolver]

[patrick-ogrady]

The quickest solution here is to find a way to enshrine this behavior (and could assert parent's are spawned before children). A more complex solution would be to refactor the code to follow the "implied" pattern (by refactoring our new()->start() pattern and instead creating inner actors during start().

The spawn depth ordering may not work in cases where calling new() creates some internal task that does something, but arguably that's good to enforce. This also paves the way to enforcing a context is called only in the scope it was created (not at the wrong "level").

[patrick-ogrady]

#1850 takes an interesting approach (just considering all as child)

[patrick-ogrady]

It may be much simpler to store the "tree" of context in "executor" rather than trying to keep context synchronized with its parents/children.

This becomes immediately clear when handling context with "skips" between levels.