Allow for top-level sibling scenario composition - composition would happen in `deployments`

[hardyjosh]

Edit: The below may be possible with regular YAML functionality: https://support.atlassian.com/bitbucket-cloud/docs/yaml-anchors/

We need to check whether it already works and if not what we would have to do to support.

---

We have a need for scenario composition that doesn't work in a strict hierachy.

At the moment in a deployment you reference one scenario, like parent.child.grandchild

The corresponding scenarios look like this:

scenarios:
  parent:
    bindings:  ...
    scenarios:
      child:
        bindings: ...
        scenarios:
          grandchild:
            bindings: ...

What we want to allow is

scenarios:
  aunty:
    bindings: ...
      scenarios:
        cousin:
          bindings: ...
  uncle:
    bindings: ...
  child:
    bindings: ...
    scenarios:
      grandchild:
        bindings: ...

Then you could create deployments like:

1. aunty.cousin.child.grandchild
2. uncle.child.grandchild

In the scenario for 1, grandchild would inherit bindings from aunty cousin and child, and in 2, grandchild would inhereit from uncle and child.

At the moment we "pre-flatten" all scenarios according to the hierachy in scenarios so they can easily be accessed by name later. Now, we would create scenarios only as needed (there is potentially too many combinations).

Edit1:

serde_yaml crate supports yaml anchors natively and works just fine

Edit2:

stringly merge the top fields of the settings and dotrain frontmatter and then deserialize them into the Config, although this needs very carefull handling of strings and positions, and what would be the case if a field like networks has a key with same name on both setting and frontmatter?

[hardyjosh]

stringly merge the top fields of the settings and dotrain frontmatter and then deserialize them into the Config, although this needs very carefull handling of strings and positions, and what would be the case if a field like networks has a key with same name on both setting and frontmatter?

@rouzwelt so I think we talked about how to do this and afaics it works - basically:

1. rename all the top level keys in settings to a unique name (like settings-networks, settings-orderbooks etc)
2. parse the whole thing into a Config that will contain both fields (ie networks and settings-networks)
3. as for your question, we would merge just as we do now with two Configs, with the same rules (e.g. no dupes allowed).

if we can do this, then we can use yaml anchors across both places with no issues.