feat: add/remove course staff role events

[ilee2u]

Description:

We are developing a new backend for exams called edx-exams. This backend will be utilized by instructor dashboards to interact with student exam attempts.

Circa Sept 2023, edx-exams has no way of knowing if a user is course staff (i.e. an instructor) or not. We'd like to avoid having this IDA call edx-platform to get this info (which would create a circular dependency), so we've decided to emit this information from edx-platform to edx-exams via the event bus (logic for the respective event producers and consumers to be deliberated later).

This PR adds event definitions for adding and removing the course staff. These events are intended to be consumed by edx-exams, but they can also be consumed in other Open edX IDAs in the future as needed.

ISSUE: MST-1918 (Internal)

In order to receive course staff info in edx-exams, we must first define events to be sent. The events should be added to https://github.com/openedx/openedx-events/blob/main/openedx_events/learning/signals.py - there should be one event for adding a course staff role, and one event for removing (or revoking) a course staff role. The data for both events should consist of a user id and a course id.

Dependencies: None

Merge deadline: None (for now)

Testing instructions:

1. Test as usual

Reviewers:

• @zacharis278

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)

Author concerns: List any concerns about this PR - inelegant
solutions, hacks, quick-and-dirty implementations, concerns about
migrations, etc.

[zacharis278]

my recent comment got collapsed as resolved but can you update the descriptions to indicate this is fired as a result of assigning course staff not a signal to assign course staff.

[zacharis278]

looks good 👍

[mariajgrimaldi]

which other fields do you think would be useful?

[ilee2u]

I added some other fields based on the current parameters that CourseAccessRole currently takes: https://github.com/openedx/edx-platform/blob/master/common/djangoapps/student/roles.py#L448

Please note that this is subject to change in the future due to the concurrent roles/permissions project that is being done (see the "IMPORTANT:" comment in the event data for more details).

[mariajgrimaldi]

That's better. Thank you!

[mariajgrimaldi]

Just a few minor comments.

[ilee2u]

Quickly reiterating what I've written in the event data docstring about this being tech debt b/c of planned changes to roles and permissions:

edX currently uses roles, and only roles, to decide what kind of access a user has. There is an ongoing project to replace this roles-only system with a system that uses roles that are made up of permissions, which is being worked on in parallel with another project to emit events whenever users are assigned any type of "Course Staff" role.

It's unclear what the state of this roles/permissions project will be the time the events project is completed, so each project's respective teams will stay in touch with each other.

For now, we're making a best effort to publish this an event that will regard the permission(s) we'd expect to "filter" for in the future (For more info, please check out this document: https://docs.google.com/spreadsheets/d/1htsV0eWq5-y96DZ5A245ukfZ4_qeH0KjHVaOyfqD8OA/edit#gid=908503896) and not for the roles we have now. Likely this/these permission(s) will be something like manage_students, but we need to evaluate how this will align with some possible future roles such as limited_staff or ccx.

As such, the current plan is to do one of the following once the roles/permissions project's feature branch is merged to master:
1. Modify this event to "filter" by the correct permissions once the
2. As a backup plan, make a new event if this proves too difficult.

Until either of these plans are executed, the comment under the IMPORTANT header should stay put.

[ilee2u]

Just fyi that I'm going to wait for #268 to be merged before changing the version and merging this PR.

[mariajgrimaldi]

These are really useful events. Thank you!

[mariajgrimaldi]

I'll wait for the other PR to be merged.

[mariajgrimaldi]

@ilee2u: the other PR was already merged!

[mariajgrimaldi]

Thank you for this! I totally missed it.

[mariajgrimaldi]

Changes release. Thank you!