Move codejail to its own new service

[jmbowman]

A/C:

• Capa problems no longer execute user-provided Python code on LMS and CMS web servers, but on separate service
• Codejail is removed from edxapp (code and requirements)
• edx-platform requirements structure is simplified to match other services: requirements/edx-sandbox/ is removed, and contents of requirements/edx/ are lifted to requirements/

Currently the underlying implementation of the codejail for restricted execution of untrusted code lives in its own repository at https://github.com/openedx/codejail, but the configuration for actually running it as a service lives here in edx-platform. This means that the core LMS repository and its Docker images are burdened with the complexities of AppArmor and an assortment of scientific computing package dependencies not used elsewhere in the LMS or Studio. To simplify these core services (especially for production environments and development tasks that don't even need a codejail environment), we'd like to try moving this functionality from edx-platform to a new IDA (name to be determined). Before diving into implementation, please consult with at least @nedbat (who wrote most of the codejail package), @ormsbee from tCRIL (who may have the best grasp on how this feature is currently used across installations), and 2U SRE (who understand operational considerations) to help enumerate requirements to inform the design.

Plan

Preview Give feedback

1. Discover and document why AppArmor and containers are a difficult combination #33753 (may change rest of plan)
2. Allow passing auth headers to codejail service: feat: Support sending OAuth token to codejail service #34023
3. Use LMS as codejail service for CMS #33538 (temporarily)
4. Set up new IDA for codejail
5. Configure CMS and LMS to use independent codejail service
6. Cleanup: Remove codejail code from LMS, make edx-platform requirements structure like that of other repos

[jmbowman]

eduNEXT already did something that is essentially this: https://github.com/eduNEXT/codejailservice . Maybe we can use it as is? We should evaluate that and figure out if we can use it or at least learn from it.

[adzuci]

I have a fair bit of context on this & would like to support this work if I can.

[jristau1984]

I have created a T&L internal Jira ticket for this issue: https://2u-internal.atlassian.net/browse/TNL-10373

[ormsbee]

FWIW, I would love to see anything that moves some of those big dependencies (SciPy/NumPy) out of edx-platform. We do use numpy in a few other places in platform (grades, course quality rating, capa complex numbers, etc), but I think that we could use the stdlib equivalents for these without too much hassle. I think that people mostly used numpy because it was already there.

[timmc-edx]

It wouldn't be hard to remove the remaining non-capa direct dependencies on numpy and scipy, but there are transitive dependencies on them via chem and openedx-calc.

[timmc-edx]

In #33753 I established that yes, we would be able to containerize LMS and CMS with codejail still in edxapp, if we wanted to. (Briefly, if we attach an apparmor profile to the container, that profile can have a subprofile for codejail confinement.) This doesn't change the desire to pull codejail out into a separate service, but it may change the urgency/timeline for deployers.