feat: add CoursewareViewStarted, CourseStartDateValidationFailed, and CoursewareAccessChecksRequested filters

[pwnage101]

Plugins can now supply a courseware view redirect URL, inject specific error
payloads when course start-date validation fails, or deny courseware access
with a priority (non-bypassable) error.

ENT-11544

---

Blocks:

• feat: add several courseware access related pipeline steps edx-enterprise#2548
• feat: decouple enterprise from courseware view redirects edx/edx-platform#338
• feat: decouple enterprise from course start-date validation edx/edx-platform#339
• feat: decouple enterprise from course access checks edx/edx-platform#340
• feat: decouple enterprise from courseware view redirects, course start-date validation, and course access checks openedx-platform#38102

[pwnage101]

@felipemontoya this is now ready for your review. For reference, the proposed call sites for all 3 added filters can be found in the draft platform PR.

Also, other unrelated repo cleanup stuff:

• Updated all outdated references openedx/edx-platform -> openedx/openedx-platform
• Fixed CHANGELOG.rst:
  • Deleted all the fragments under changelog.d/ since they are supposed to be deleted automatically by make changelog.
  • Manually incorporated those deleted fragments into CHANGELOG.rst.
  • Fixed a bunch of broken and malformed changelog entries (missing headers, wrong dates, etc.)
  • Added my own changelog entry using the new make changelog-entry / make changelog mechanism.

[felipemontoya]

Reviewing now.

For future reference @pwnage101, whenever you need to do a lot of cosmetic changes its better to keep those in a separate PR. Those I can merge easily and that makes reviewing the actual change in the filters easier.

[felipemontoya]

Overall the 3 filters make are well defined, correctly documented and are new places in the platform cycle not covered by previous filters. I'd like to hear from the RBAC devs before merging but otherwise I approve.

[felipemontoya]

This filter makes a lot of sense to me.

If I understand correctly this goes first in the stack, right?

1. CoursewareViewStarted
2. VerticalBlockChildRenderStarted
3. Loop over RenderXBlockStarted
4. VerticalBlockRenderCompleted 

[pwnage101]

To be completely honest, I don't 100% know. My goal with this ticket is a 1:1 replacement, so I'm pretty laser focused on replacing the exact call sites. That said, filter naming is important, so it is a good idea to understand the code path to come up with a self-documenting name.

The best I can tell, there are 2 code paths that can trigger a DSC redirect when a learner views courseware (legacy vs. MFE), and they use different filters:

Legacy (server-rendered) courseware views:

1. CoursewareViewStarted (view decorator / WikiAccessMiddleware)
   • If DSC redirect is needed, returns an HTTP redirect here.
2. loop over VerticalBlockChildRenderStarted
3. VerticalBlockRenderCompleted

Learning MFE — two separate requests:

• Request A — course_home_api/course_metadata BFF call:
  1. CoursewareAccessChecksRequested (from check_course_access)
     • If DSC redirect is needed, returns the error_code = data_sharing_access_required and developer_message = <consent URL> in API response.
     • MFE reads developerMessage as the consent redirect URL, performs redirect via javascript.
• Request B — render_xblock:
  1. RenderXBlockStarted
  2. loop over VerticalBlockChildRenderStarted
  3. VerticalBlockRenderCompleted

[felipemontoya]

Do you think this must connect with the RBAC project in any meaningful way?

@mariajgrimaldi or @BryanttV do you see any cause for concern with a filter like this?

[pwnage101]

I'm not sure, this is the first I've heard of the "RBAC project" (openedx/openedx-authz), having only contributed to openedx/edx-rbac which we use extensively to manage role-based authorization for all of our enterprise IDAs.

[felipemontoya]

This filter also makes a lot of sense to me. I'd also like to see how this interacts with RBAC for future-proofing purposes.