feat: Upstream Sync with Content Library Blocks

[kdmccormick]

Changes:

• Expose version_num from ContentLibraryXBlockMetadata
• Create a new UpstreamSyncMixin which is added to all CMS blocks, including:
  • New fields upstream, upstream_version, upstream_overridden, and upstream_settings
  • An upstream_link XBlock GET/PUT handler for getting/setting a block's link to a library block
  • An update_from_upstream XBlock handler for pulling in library update
• TEMPORARY: Display upstream version info in the block title, for debugging

[kdmccormick]

@bradenmacdonald So I've got this draft version of upstream sync working, implemented with XBlock fields and handlers. Using the XBlock fields and handlers for this was nice because it gave me persistence, URL routing, and OLX serialization for free.

But now I'm wondering if this is bad approach because we'll need to support Units and Subsections in libraries next, and we've agreed that those structural blocks should stop being XBlocks eventually.

The alternative I see is to:

• use Django models to store upstream links, upstream defaults, and upstream overrides,
• define REST/Python APIs for managing them, and
• handle OLX serialization as special case

Thoughts?

[kdmccormick]

use Django models to store upstream links, upstream defaults, and upstream overrides,

Okay, I started prototyping this, and it's easier said than done. Particularly, if you imagine a model like this, there's a question of whether we FK to entities or entityverisons:

class UpstreamDownstreamLink(models.Model):
    """
    Link a piece of content (the downstream) to a source for updates (the upstream).
    """
    # Pretty straightforward -- FK to a particular upstream version, and then update the
    # version whenever sync happens.
    upstream = models.ForeignKey(PublishableEntityVersion)

    # Which one of these is right?? Neither?

    # This one would apply to all versions of the downstream component, so it would play weird
    # draft/publish, and would fail if we ever added an "undo" button to studio.
    downstream = models.OneToOneField(PublishableEntity)

    # This seems more correct, but would require updating every time a new version of the downstream
    # component is created. Perhaps this would work fine as a cache, but it seems wrong as the authoritative
    # data source.
    downstream = models.OneToOneField(PublishableEntityVersion)

It seems to me, then, that we do want to persist upstream metadata using XBlocks fields, so that version management works as we expect. Still, I'm open to feedback on whether we should use XBlock handlers vs. build a separate REST API for getting/settings links and syncing from upstream.

[open-craft-grove]

Sandbox deployment failed 💥 Please check the settings and requirements. Retry deployment by pushing a new commit or updating the requirements/settings in the pull request's description. 📜 Failure Logs ℹ️ Grove Config, Tutor Config, Tutor Requirements