Push more logic down from openedx-platform into openedx_content

[kdmccormick]

Content Libraries API, in particular -- much of this could be in openedx_content

ContainerMetadata could be moved down

Does this mean making openedx-core depend on opaque-keys?

[bradenmacdonald]

Content Libraries API, in particular -- much of this could be in openedx_content

Up to this point, openedx-core has not been "aware" of Content Libraries, and its only reference to Learning Contexts / Courses in the new catalog app which tracks course runs.

We could move some of the libraries API here, either as part of openedx_content or some other app, as long as it's clearly enforced that it's a high-level thing built on top of the other low-level content primititves.

However, I'm not sure we can do that soon, as the libraries API in platform has a lot of celery tasks, event signals, event handlers, authz interactions, etc. that we don't have the infrastructure for in this repo (yet?). We could try to pick some subset of that like the actual ContentLibrary model and the metadata dataclasses for them. But I'm not sure that's a huge benefit, because right now the content_libraries app in openedx-platform is fairly nicely encapsulated.

[bradenmacdonald]

ContainerMetadata could be moved down

I think the only thing we're missing to be able to do that is a way to get the opaque key (so far it's always a LibraryContainerLocator) for the given container. But without the libraries code being in core (see above), I'm not sure we have any way to get that information; we just have the learning package and the container ID.