Refactor authorization checks

[jmbowman]

The Roles and Permissions squad has been doing some work to clean up and enhance the use of authorization in Open edX, resulting in:

• OEP-66: Authorization Best Practices (including an overhaul of OEP 9: User Authorization (Permissions))
• The Permissions Checks discovery findings

We would like to start the unfinished followup from OEP-9 of starting to switch over existing authorization checks in the Open edX code to follow the recommended pattern (basically "Django authorization API using bridgekeeper as the backend)."

A/C:

• Write up an execution plan in the Open edX Confluence for switching over the code identified in the discovery doc to switch over to the recommended API from OEP-66. No business logic should be changed at this point, just separation of authorization check implementations from usage (and de-duplication of essentially identical helper functions).
• Communicate the plan and timeline to stakeholders (owning teams, SRE, etc.) and adjust as needed based on feedback
• Chunk the work from the discovery doc into separate issues that can be worked on in parallel, and add them to a tasklist in this issue
• Merge and deploy at least 1-2 PRs to shake out any bugs in the process before starting work on the remaining issues
• Complete the remaining issues generated above
• Do another round of discovery for any similar refactoring that still needs to be done, and create a new issue for it
• Perform a retrospective on the process and schedule or shelve the next round of refactoring as appropriate

[iamsobanjaved]

bridgekeeper had last commit 2 years ago, and last release 3 years ago

[jmbowman]

The topic of bridgekeeper maintenance status came up in https://twou.slack.com/archives/C04B987KHK5/p1694531725289039 . rules is more actively maintained, but isn't really getting any new features; bridgekeeper is ahead in terms of useful features, but behind on routine maintenance. I think our first preference right now is help the bridgekeeper maintainer catch up on Python & Django version testing, with forking as a fallback if that doesn't work out. Sticking with rules would leave us with less maintenance overhead but a feature gap that we'd have to figure out how to plug (and the rules maintainer has been opposed to adding those features; see dfunckt/django-rules#40 for context).