- Remove usage of django.urls.patterns
- Change urls tuples to lists
- Make all string view names callables
- This is the second of several urls updates for LMS; a work in progress

LEARNER-76

These changes unify four different approaches to JWT creation, moving the core of the AccessTokenView to a general-purpose JwtBuilder class. This utility class defaults to using the system's JWT configuration, but it will allow overriding of the signing key and audience claim to support those clients which still require this. Part of ECOM-4566.

More accurately, this creates a 4th shard because the
last shard is always the default.

More accurately, this creates a 4th shard because the
last shard is always the default.

MA-1998 Install and configure django_oauth_toolkit to coexist with
existing oauth libraries.

TNL-2444

TNL-4243

TNL-4164

TNL-4043

TNL-4108

TNL-2816

TNL-4012

TNL-3908

TNL-3840

- Remove escaping in display_name_with_default
- Move escaped version to deprecated display_name_with_default_escaped
- Does not include any other changes to remove double-escaping

Thanks to agaylard who initiated this work:
https://github.com/edx/edx-platform/pull/10756

TNL-3425

Extends the Programs ConfigurationModel, cleans up Programs-related utilities and corresponding tests, and corrects caching. Uses the Programs API to list programs within Studio. ECOM-2769.

ECOM-2578

TNL-2321

TNL-2172

This new endpoint is intended to replace enrollment API call used on the login+registration page. Instead of directly enrolling students, the view will contact the external e-commerce API (Oscar) to create a new order. Oscar will be responsible for completing the order and enrolling the student.

This behavior will only apply to course modes with associated SKUs. All other course mode enrollments will be processed directly by LMS.

The existing pattern of using `override_settings(MODULESTORE=...)` prevented
us from having more than one layer of subclassing in modulestore tests.

In a structure like:

    @override_settings(MODULESTORE=store_a)
    class BaseTestCase(ModuleStoreTestCase):
        def setUp(self):
            # use store

    @override_settings(MODULESTORE=store_b)
    class ChildTestCase(BaseTestCase):
        def setUp(self):
            # use store

In this case, the store actions performed in `BaseTestCase` on behalf of
`ChildTestCase` would still use `store_a`, even though the `ChildTestCase`
had specified to use `store_b`. This is because the `override_settings`
decorator would be the innermost wrapper around the `BaseTestCase.setUp` method,
no matter what `ChildTestCase` does.

To remedy this, we move the call to `override_settings` into the
`ModuleStoreTestCase.setUp` method, and use a cleanup to remove the override.
Subclasses can just defined the `MODULESTORE` class attribute to specify which
modulestore to use _for the entire `setUp` chain_.

[PLAT-419]