feat: new COURSE_CATALOG_INFO_CHANGED signal for course_authoring

[rgraber]

Description:
Adds a new OpenEdxPublicSignal to describe the changing of the catalog information for a course

Issue: #72

Reviewers:

• tag reviewer
• tag reviewer

Merge checklist:

• All reviewers approved
• CI build is green
• Version bumped
• Changelog record added
• Documentation updated (not only docstrings)
• Commits are squashed

Post merge:

• Create a tag
• Check new version is pushed to PyPI after tag-triggered build is
  finished.
• Delete working branch (if not needed anymore)

[robrap]

Nice. Lots of minor questions/comments that hopefully aren't too controversial.

[ormsbee]

Some questions (mostly because I'm not as familiar with this data as I should be).

[rgraber]

@ormsbee @robrap
As I understand it, the problem is that we don't send media across in a consistent format in the LMS API call that we're trying to replace, nor does Discovery save in a consistent format. For course_video, we send both relative URI/path and absolute URI/URL. For banner_image and course_image we just send a path, and for image we send over three full URLs for raw, small, and large.

After some discussion, I think our options are

1. Copy the existing fields exactly as they are from the LMS response and just acknowledge that they are weird and inconsistent. We could still fix the field names to be a little clearer.
2. Create an ImageData attrs-class with path and URL fields. Use this class for video, banner_image, and course_image. Then, create a SizedImageData class that is just three ImageData attributes, one each for raw, small, and large. Make any bits we can't always populate optional.
3. Always send just the URL and let clients deal with extracting the path.

Notes:
For (2), we might end up with a lot of optional fields which isn't great for consumers
For (3), we're not sure if we can get the absolute uri from within Studio

@robrap 's order of preference is (3) then (1). This preference for (3) assumes we are able to get absolute uris from within Studio without too much headache and then strip down to a relative path in Discovery with a similarly small headache. He really doesn't like (2) because of the confusing nature of a bunch of optional fields.

My order of preference is (1) then (3), though it's not a terribly strong preference and is mostly in service of getting this out quicker. I agree (2) has the potential to be very confusing and doesn't save that much work over (3). If (3) is quick, then I'm all for it, I'm just not sure how long it will take to determine if it's quick.

I think both of us agree we can at least start with 1, and then when implementing the actual event in Studio determine if we could do 3 without much more effort.

[rgraber]

As far as I can tell, while it used to be possible to edit media in Studio, it is not possible any more. This would suggest all the various media fields sent over from the lms to discovery are legacy. We could turn on some temporary logging in discovery to see if it ever actually updates course media as a result of RCM to support this hypothesis.

[rgraber]

For posterity, the decision was to drop all the media fields since they are unused by course-discovery. See the deprecation ticket at openedx/public-engineering#160 .

[robrap]

I'm basically all set, other than resolving Dave's comments. Thank you.

[timmc-edx]

[nit] org/number are in a different order here than in the attributes.

[timmc-edx]

[nit] hidden uses (optional) on a bool with a default, but invitation_only does not.

Suggested change

	hidden (bool): whether the course is hidden from search (optional)
	hidden (bool): whether the course is hidden from search (optional)

[rgraber]

The eventual ADR around this event design ended up here: https://github.com/openedx/openedx-events/blob/main/docs/decisions/0009-course-catalog-info-changed-design.rst