Modeling XBlock field inheritance [WIP]

TLDR: We should model field data lookups/overrides separately from the concept of parent-child relationships when it comes to rendering XBlocks.

This idea is at the intersection of a few different lines of conversation that we've been having recently, including:

• Trying to stitch together Learning Core models with the Split ModuleStore. (To be clear though, this idea would likely not factor into the prototype or even the initial migration.)
• @kdmccormick's question in our last meeting w.r.t. parents affecting children and what that means for calculating their state changes (since side-effects are child -> parent).
• The idea that under the covers, parent-child relationships are on their way out of the XBlock runtime, since that will be taken over by Learning Core models.
• Product conversations around settings for various container types.

Original Thought: Store parent-child relationships

I was originally trying to model parent-child relationships for the draft and published version of an XBlock, potentially as a fat table with one column per layer, or maybe a thin one with an explicit order number. The idea would have been to allow for fast querying of "what are my ancestors in order, so that I can compute my fields quickly". The table would be a bunch of foreign keys, so we're not repeatedly storing the field data over and over again, like we do for block transformers.

Hypothetical Use Case: Assignment Type Defaults

Then I was thinking of what it would mean for us to have default field values associated with an assignment type in the grading policy (e.g. "you get 3 attempts, answers only shown after due". Today, it would mean that we somehow manually copy/sync the assignment type-associated settings into the subsection. But I think in the future, we'd want a world where the assignment type represents a new settings layer above Subsection. People could still tweak policies for individual assignments to be different, but they could set general policies for Homework, Quizes, etc.

That's when it hit me: when it comes to computing the field values for LMS rendering an individual block, the runtime doesn't need to think in terms of parent-child relationships. That's usually the precedence ordering (though not always, given weird v1 library edge cases). But that's not the critical part.

I believe the critical part that the XBlock runtime needs to understand is just, "Give me an ordered list of dicts that I search through when trying to find a field value, with an indication of where these dicts are coming from so that I can present it to the user if necessary." Parent/child understanding happens at the authoring layer, but the XBlock runtime gets the compiled output.

These Usages also don't have to be 1:1 with our Component models. In this framing, the Usage isn't the Component. The Component just provides the most specific set of content and settings field data that go into composing a Usage.

Start by reading the linked edx-platform/xmodule/modulestore/inheritance.py section and the issue's discussion of Learning Core, Split ModuleStore, Component, and Usage models. Clarify the intended data model and scope with maintainers before identifying an implementation entry point; done should include an agreed design for ordered field-data layers and their source metadata.