Backport the upstreamed Bulk Enroll API

[bdero]

Part of: https://tasks.opencraft.com/browse/OC-2453

Cherry-picked from PRs:

• https://github.com/edx/edx-platform/pull/15006
• https://github.com/edx/edx-platform/pull/15584
• https://github.com/edx/edx-platform/pull/15579

[bdero]

Note: I removed this fix, which is not compatible with the version of DRF used in Ficus: https://github.com/edx/edx-platform/pull/15584

See this PR for details!: https://github.com/edx/edx-platform/pull/15631

CC @pomegranited

[pomegranited]

@bdero Does it make sense to include both https://github.com/edx/edx-platform/pull/15584 and https://github.com/edx/edx-platform/pull/15631 in this change?

Since setting the request.POST parameters explicitly is non-standard, it seems like letting the JSON data come in as a POST parameter is a cleaner solution for all versions of django-rest-framework.

[bdero]

@pomegranited There was some pretty significant refactoring that happened between the version of DRF that Cloudera is using and edx:edx-platform/master. Since the DRF request POST parameters are not a property in the Cloudera version of DRF, I suspect that setting the content type in the underlying Django request won't result in the POST params being pulled from the data dict. (It's possible this behavior still exists through a dunder hook or similar, but I couldn't find anything relevant in the code)

[pomegranited]

@bdero No worries, thanks for your explanation.
👍

• I tested this on the appserver deployed from this branch.
• I read through the code
• I checked for accessibility issues
• Includes documentation - cherry-picked code, no extra docs required.

[bdero]

@pomegranited Thank you!