Follow-ups from Learning Core Switchover

[kdmccormick]

Following up on #34066 ...

Tasks

Beta Give feedback

1. ADR for Public Python API Conventions openedx-learning#186
   +0
2. Refactor to authoring package openedx-learning#184
   +0
3. Support static assets in the Learning Core runtime #34737
   content libraries misc +1
   
4. Write up a high level description Learning Core openedx-learning#167
   +0
5. [DEPR]: Blockstore public-engineering#238
   11 of 11
   depr +1
   

   
6. Rip out def_key from LibraryXBlockMetadata (does this require frontend code changes?)
7. All content libraries misc tickets: https://github.com/openedx/edx-platform/issues?q=is%3Aissue+is%3Aopen+label%3A%22content+libraries+misc%22
8. Better consolidate some of the runtime related logic. I've written "get the component for this usage key" at least three times.
9. Make Content and file data for content 1:1 by encoding the mime type as part of the file saved... (? though this would make changing mimetypes text much more expensive...) Anyhow, figure this out while implementing static asset support.
10. Figure out what fields are actually needed in the library listing view and optimize the data model if necessary (things like publish status and count are somewhat expensive to aggregate right now). Can be punted if it's not necessary for MVP.
11. See if we can remove some of the computations that would be more expensive from the get_metadata() calls that are meant to operate over a queryset of libraries (things like getting the size of a library, whether there are unpublished changes, etc.)–these queries are fine for any one particular library, but the expense scales with the size of the library, and we probably don't want it in a list view.
12. Figure out how we really want to model the LibraryKey
13. In order to make duplication and import work robustly, write and implement ADRs around the do-not-query-old-libraries-versions decisions.
14. Maybe we can use slugs rather than UUIDs for the UsageKeys of blocks in libraries? We could make them type in the title in a modal when creating a new block, and use a slug of that maybe? We could also allow them to freely change it until they publish (after which we preserve it so that content linking to it doesn't break)?
15. Make get_block return Draft vs Published based on an initialization parameter. Currently it's hardcoded to Draft because we're just supporting CMS for now.
16. Avoid importing from openedx-learning models; perhaps even use importlinter to enforce this. Models we need should be exposed through api.py. Better yet, we should return data objects instead of models.
17. Figure out how to write a get_library_blocks function that returns a queryset of XBlock metadata objects rather than a list.
18. chore: unpin django-stubs now that we're on django 4.2 #34237
    +0
19. Remove unnecessary type-ignore comments once ^ merges
20. Remove whole-library version number from REST API
21. Handle cases where content_library.learning_package is None