Explicitly model publishing dependencies

[ormsbee]

Containers functionality currently lives in the publishing app because containers and publishing are tightly coupled – publishing a child affects the parent's published state, and publishing the parent should publish children. We've discussed how if we were to separate them into different apps, we'd have to build some more complicated signal-based system where containers would have to listen to publishing for certain events and potentially inject parents or children into those actions, implement some callbacks, etc. I think we all have the intuition that container logic doesn't really seem like it fits in with other publishing things, but as long as it is coupled, it's better to make it obviously coupled, rather than get obtusely abstract about the coupling.

When thinking about this separation, one of the things that bothered me was the idea that the publishing app might not have all the information it needs in order to do things like determine side-effects. Folding containers into publishing side-steps the problem for now, but direct container-child logic won't be the only kind of side-effect / dependency once we start modeling courses.

Then it hit me: I think we weren't properly translating the concept of publishing dependencies from the point of view of the publishing app, i.e. publishing shouldn't care about containers, parents, and children — it should care about dependencies and side-effects. There's a gap in the data model.

I don't have this completely baked yet, but a few high-level thoughts:

1. The publishing app doesn't need to care about the entire history of dependencies, only the dependency relationships of the current draft and published versions of something.
2. The definition of whether or not a change in a child has a side-effect on a parent is defined purely by the data in a specific version of the parent. Say I define a UnitVersion to have an unpinned child Component C1. No future change to C1 is going to undo that dependency/side-effect relationship (even deletion).

Given that, I think we can make a publishing API call that is something like set_dependencies(draft, publishable_entities). Containers would call this whenever they make a new version, and we'd stuff it in a model or two (since we need to track both draft and published versions).

With that information, I think publishing can do some really nifty things:

1. Calculate side-effects very simply, and without invoking any sort of callbacks.
2. Implement an optional publish_dependencies boolean param so that publish can publish nested dependencies, without having to care about how Containers or (later on) Courses model their relationships (e.g. grading policies).
3. Implement a draft/published state summary hash for anything with dependencies, since the entire draft state or published state of an entity is a product of its own version + the versions (EntityVersion.uuid) and state summaries of all its children (with components having no separate state summary because they're fully described by their version). The publishing app will have all of that.

FWIW, I don't think it's particularly urgent for us to move Containers out to its own app. I think that making this kind of abstraction and data model would be useful regardless, especially as we move to non-container dependencies in Courses.

[ormsbee]

@kdmccormick, @bradenmacdonald: I pulled the thread a bit on my last PR comment, and this is the result. Please let me know what you think when you have time.

[ormsbee]

Edge case thoughts:

1. Should the state calculation for a container's dependencies include deleted dependencies? Or to put another way: Is the state hash for "three children where one is deleted" exactly the same as "two children, omitting the deleted one"? I'm leaning towards the two states being the same, i.e. skip deleted entries.
2. Since the state hash is based purely off of the dependencies (we might just call it the dependencies_state_hash), we can be in a place where the hashes are identical for two different containers, or two different versions of the same container (re-ordering). This is okay, and maybe even useful for comparisons.