Please note that this is a squshed commit and the work of:
Symbolist, macdiesel, nedbat, doctoryes, muzaffaryousaf and muhammad-ammar

* Upgrade edx-submissions
* Upgrade edx-ora2
* Upgrade edx-val
* Upgrade edx-proctoring
* Update all edx-platform code that depends on DRF, including:
  - auth_exchange
  - cors_csrf
  - embargo
  - enrollment
  - util
  - commerce
  - course_structure
  - discussion_api
  - mobile_api
  - notifier_api
  - teams
  - credit
  - profile_images
  - user_api
  - lib/api (OAuth2 and pagination)

* Upgrade edx-submissions
* Upgrade edx-ora2
* Upgrade edx-val
* Upgrade edx-proctoring
* Update all edx-platform code that depends on DRF, including:
  - auth_exchange
  - cors_csrf
  - embargo
  - enrollment
  - util
  - commerce
  - course_structure
  - discussion_api
  - mobile_api
  - notifier_api
  - teams
  - credit
  - profile_images
  - user_api
  - lib/api (OAuth2 and pagination)

TNL-3204

This change allows graded assignments to be added to a campus LMS
regardless of the granularity at which the problem sits. Previously
a grade could only be returned if the usage ID for the problem itself
was specified in the LTI launch.

The code assumes that courses taking advantage of this functionality
are arranged in a hiearchy (with sections being parents to verticals,
and verticals being parents to problems). When a grading event occurs
it traverses the parent hiearchy to identify any previous graded LTI
launches for which the new scoring event should generate a grade
update. It then calculates and sends scores to each of those outcome
services.

Since grade calculation is an expensive operation, the code optimizes
the case where a problem has been added only once as a leaf unit. In
that case it is able to behave as before, just taking the grade from
the signal without having to calculate grades for the whole course.

TNL-2879

The progress page did a number of things that make performance terrible for
courses with large numbers of problems, particularly if those problems are
customresponse CapaModule problems that need to be executed via codejail.

The grading code takes pains to not instantiate student state and execute the
problem code. If a student has answered the question, the max score is stored
in StudentModule. However, if the student hasn't attempted the question yet, we
have to run the problem code just to call .max_score() on it. This is necessary
in grade() if the student has answered other problems in the assignment (so we
can know what to divide by). This is always necessary to know in
progress_summary() because we list out every problem there. Code execution can
be especially slow if the problems need to invoke codejail.

To address this, we create a MaxScoresCache that will cache the max raw score
possible for every problem. We select the cache keys so that it will
automatically become invalidated when a new version of the course is published.

The fundamental assumption here is that a problem cannot have two different
max score values for two unscored students. A problem *can* score two students
differently such that they have different max scores. So Carlos can have 2/3 on
a problem, while Lyla gets 3/4. But if neither Carlos nor Lyla has ever
interacted with the problem (i.e. they're just seeing it on their progress
page), they must both see 0/4 -- it cannot be the case that Carlos sees 0/3 and
Lyla sees 0/4.

We used to load all student state into two separate FieldDataCache instances,
after which we do a bunch of individual queries for scored items. Part of this
split-up was done because of locking problems, but I think we might have gotten
overzealous with our manual transaction hammer.

In this commit, we consolidate all state access in grade() and progress()
to use one shared FieldDataCache. We also use a filter so that we only pull
back StudentModule state for things that might possibly affect the grade --
items that either have scores or have children.

Because some older XModules do work in their __init__() methods (like Video),
instantiating them takes time, particularly on large courses. This commit also
changes the code that fetches the grading_context to filter out children that
can't possibly affect the grade.

Finally, we introduce a ScoresClient that also tries to fetch score
information all at once, instead of in separate queries. Technically, we are
fetching this information redundantly, but that's because the state and score
interfaces are being teased apart as we move forward. Still, this only
amounts to one extra SQL query, and has very little impact on performance
overall.

Much thanks to @adampalay -- his hackathon work in #7168 formed the basis of
this.

https://openedx.atlassian.net/browse/CSM-17

* Handle grading errors

add doc strings; fix pep8 warning
address some minor issues brought up by the code review process

Final official name is Custom Courses for EdX (CCX), rename all code to remove previous name.

Rename the FEATURE constant used to identify this feature

Rename the middleware for the CCX change

rename the constant used for storing the current poc id on the session.

rename the _PocContext threading local

rename the override provider in all places where it is referenced

`PersonalOnlineCoursesOverrideProvider` -> `CustomCoursesForEdxOverrideProvider`

generally rename symbols from overrides.py to replace `poc` with `ccx` where possible without changing model names or attributes

rename more symbols from poc to ccx
rename util functions from app utils module

general symbol renaming poc -> ccx in views.py and related url changes

Rename the coach role wherever it is used.

reword poc_coach to ccx_coach

UI rename

replace POC with CCX globally

template context variable renamed

rename poc_ to ccx_ in urls and all related locations (views, js, scss etc)

remove pocs migrations

Final massive renaming, including models.  Re-built migration.

cleaning up a few tailing references

Fix reference typo in schedule template JS

undo modifications made on the fly in test setup to ensure that our tests are properly isolated from the rest of the system tests.

Fixes jazkarta/edx-platform#38

Clean up some leftover strings and comments

fixing more strings and comments in python files

fix a naming error in the schedule tab that was causing problems in deleting courseware items.

Fixes jazkarta/edx-platform#36

updating tests and utility code to match changes in infrastructure from latest rebase

individual students, and a reimplementation of the individual due date
feature.

This work introduces an architecture, used with the 'authored_data'
portion of LmsFieldData, which allows arbitrary field overrides to be
made for fields that are part of the course content or settings (Mongo
data).  The basic architecture is extensible by means of writing and
configuring arbitrary field override providers.

One concrete implementation of a field override provider is provided
which allows for overrides to be for individual students.  This provider
is then used as a basis for reimplementing the individual due date
extensions feature as a proof of concept for the design.

One can imagine writing override providers that provide overrides based
on a student's membership in a cohort or other similar idea.  This work
is being done, in fact, to pave the way for the Personal Online Courses
feature being developed by MIT, which will use an override provider very
much long those lines.

for visual indent

addresses part of LMS-2907

Install edx-submissions from PyPi instead of from edx-ora2

This commit updates lms/djangoapps/courseware.

These keys are now objects with a limited interface, and the particular
internal representation is managed by the data storage layer (the
modulestore).

For the LMS, there should be no outward-facing changes to the system.
The keys are, for now, a change to internal representation only. For
Studio, the new serialized form of the keys is used in urls, to allow
for further migration in the future.

Co-Author: Andy Armstrong <andya@edx.org>
Co-Author: Christina Roberts <christina@edx.org>
Co-Author: David Baumgold <db@edx.org>
Co-Author: Diana Huang <dkh@edx.org>
Co-Author: Don Mitchell <dmitchell@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Nimisha Asthagiri <nasthagiri@edx.org>
Co-Author: Sarina Canelake <sarina@edx.org>

[LMS-2370]

Support for displaying submissions API scores in Progress page.

Adds a feature to the edX platform which allows instructors to set
individual due dates for students on particular coursework. This code is
meant primarily for on-campus use--it is not intended that this feature
would be used for MOOCs. It adds a new tab, "Extensions", to the beta
instructor dashboard which allows changing due dates per student. This
feature is enabled by setting FEATURES['INDIVIDUAL_DUE_DATES'] = True.

This restores functionality that has been broken since the introduction of
XModuleDescriptor/XModule proxying (part of the XBlock transition). It generates
a CSV of all answers for all content of type "problem" in a given course, with a
row per (problem part, answer). The format is:

url_name, display name, answer id, answer, count

Example values:
  url_name = "7f1b1523a55848cd9f5c93eb8cbabcf7"
  display name = "Problem 1: Something Hard"
  answer id = i4x-JediAcdmy-LTSB304-problem-7f1b1523a55848cd9f5c93eb8cbabcf7_2_1
  answer = "Use the Force"
  count = 1138

Since it only grabs things of type "problem", it will not return results for
things like self/peer-assessments. Any Loncapa problem types will show up (so
multiple choice, text input, numeric, etc.)

Instead of crawling the course tree and instantiating the appropriate CapaModule
objects to grab state, this version draws directly from StudentModule. This lets
us skip a lot of processing and most importantly lets us generate the answer
distribution without causing side-effects (since XBlocks auto-save state). It
also lets us take advantage of a read-replica database if one is available, to
minimize locking concerns.

There are minor changes to the legacy dashboard around CSV charset encoding and
a change to OptionResponseXMLFactory to make it more unicode friendly. Answer
distribution output is now also sorted, to group together answers for the same
content piece.

Note that this does not introduce celery into the process. Answer distributions
are still only available for small courses.

This was originally created to fix [LMS-922], but it also addresses [LMS-811] and
possibly other areas in the legacy dashboard where CSV downloads break due to
character encoding issues.

remove field_data_cache from grades.grade and grades.progress_summary

cleans grading code by adding wrappers

that are not present in a given student's gradeset.

General code cleanup and addition of comments.

Instructor dashboard API unit tests.

LMS-58

Hook up display of grade files ready for download to new instructor dashboard.

LMS-58