wip: add demo topper definition

[adgad]

What is this?

This draft PR is a loose implementation of what a topperTree could look like. Ignore the details - it's mostly a place to start the conversation about feasibility and desirability.

Why do I think it's desirable?

bodyTree has served us well for creating a common and consistent language to describe the full representation of an article body, and the data required for it.

Toppers do not have the same luxury - the structure of a topper (in Spark/C&M) has been largely unchanged since 2017. Data in C&M lives in a bunch of fields: core fields like headline, standfirst, some things in topper, leadImages, leadFlourish. There's also a lot hidden of inferred decisions made in business logic in CP.

We're now looking to add (clips and/or custom components) to toppers, and it seems like a nice opportunity to start thinking about whether we can apply some of the same thinking and reap the same benefits with toppers, to result in a more consistent, reusable data models.

How will it work (in theory)?

1. We define a topperTree data structure
2. Update cp-content-pipeline-api to start using that
3. (Extract some shared business logic out of CP content pipeline so it can be used in Spark)
4. Spark generates and publishes the topperTree transit data structure to C&M
5. C&M validate the data structure using JSON schemas generated in this repo
6. CP start reading the topperTree data structure from the new C&M read API (which we'll also be doing for bodyTree)

What are some of the questions/challenges?

• What do we do about fields that are inferred from other content things (e.g. metadata)? Does external still make sense?
• We have some things that are editorially published, but possibly later overridden (e.g. backgroundColor)
• To what extent does this fit with existing topper implementations?
• What about old content? Would we need to migrate anything??
• What can we simplify to make it work better? e.g. can we move some decisions to more explicit editorial ones?
• To what extent could we implement this incrementally (in particular to get a working clip/ccc in topper)?
  • We would b
• (related) is it possible to "virtually" build out the topperTree, without publishing, to iron out the model?

[adgad]

should these be keys rather than children? allows for further growth?

[adgad]

i think it does make sense.

the benefit of having them as children i guess would be if there wasn't a regimented structure, and the FE could receive/render anything (like we do with RichText).

this probably isn't true for the topper