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

Remove unused Ruby gems

Fix 'stuck in publish issue' when deleting a component

Fix hinted login view to be compatible with secondary providers.

Added more descripted release script message

These were only used by rake, and we haven't used rake in a year.

TNL-2665 Prevent Taiwan from being translated

Update LMS student dashboard to use CourseOverview

Disable flaky GroupConfigurationsPage JS test TNL-1475

Revert "Update copy for On Demand Cert Download"

Update copy for On Demand Cert Download

Fix flaky js tests caused by ajax requests TE-970

[LTI Provider] Refactoring to remove the lti_run method

Make the release script use the primary email from people.yaml

Fixed 'play_video' event which was emitting with wrong params.

This change is a follow-up to the chages in PR 8347, which removed the
edX login page from the workflow for a new user. Where previously we
redirected a user to the login page, PR 8347 instead creates a new user
transparently and logs them in.

The initial reason for splitting the LTI view between lti_launch and
lti_run was so that there was a target for the GET request that
followed the login page. Since we no longer use the login page, we
no longer need the second view. We also don't need to store the LTI
parameters in the session any more, since they are not persisting
between calls. This simplifies the view logic significantly.

The other change here is to fetch the LtiConsumer object early in
the view, and pass it to the SignatureValidator and scoring system.
When the views were split, this required multiple DB hits for the
same data; we're now only fetching it once.

ECOM-1651

"play_video" event emitted after seeking forward in a video contains old position

ECOM-1601: Added the help link of credit info

[NEW] - Fixed randomized problems which were not appearing to work.

Remove the DjDT profiling panel from devstack.py. It appears to cause…

mattdrayer/num-queries-fix: Update query value to reflect new reality

Fixing aria values and contrast for accessibility

ziafazal:SOL-1011: Certificate URL should use 'download_url' field and not 'verify_uuid'

Merge release into master

Remove the DjDT profiling panel from devstack.py. It appears to cause horrendeous performance issues, while offering very little benefit.