Improve client-side performance.

TNL-2945

* Combine verification and reverification photo submission end-points.
* Combine verification and reverification Backbone models.
* Allow deletion of verification status in Django admin.
* Initial verification from a checkpoint is associated with the checkpoint.
* Fix critical bug in which an invalid link was sent to Software Secure
  for the photo ID image of reverification attempts.

TNL-2413

TNL-2413

ECOM-1796
ECOM-1525

TNL-2602

TNL-2487

Add context for navigation states
added find course to dashboard sidebar and included check for context that Will adds in PR
removed nav_course_search context due to design change so replaced with nav_hidden
Removed rwd_header.js and all references as no longer being used.

Wrapped Find Courses in dashboard sidebar in if statement

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

This reverts commit c94abd27.

This reverts commit 85b3bfe4.

This reverts commit c94abd27.

This reverts commit 85b3bfe4.

Templates that display the image now check if courses specifies an image, if they don't the default image is displayed

Path set in both common.py and aws.py to allow for easy overriding in one place.

Addresses SOL-926

Some code provided by Davorin Sego

Authors:
  - Daniel Friedman
  - Ben McMorran
  - Peter Fogg

TNL-1892

TNL-2305

add flag to lms/envs/common

update edx-search release tag

* updated the flags for social media sharing
* added facebook feed ui to share public url
* update the condition logic
* update the code as per suggestion and added pick new style for share buttons
* update the css class reference
* update the bok-choy test
* updated description and some text touch-ups
* moved the JS related to facebook into separate location
* js formatting
* Add trailing comma per chrisndodge
* Add wait to fix flaky test...maybe

This feature flag gates the exposure of the Full course/library
Import/Export API URLs in the LMS. This allows openedX deployments
that operate without Studio to take advantage of the API, while
others may turn the feature off to reserve all content authoring for
Studio.

This is a public, versioned, RESTful API for importing and
exporting full course content. The code was initially ripped from the
existing import/export API in the CMS contentstore djangoapp and wrapped
in Django Rest Framework view classes. It's a new djangoapp in
the openedx directory which is largely an abstraction off the CMS
Import/Export views.

This PR includes configuration changes. Most notably, Studio is
configured to serve the OAuth2 provider alongside the LMS.

This is the initial thread on the code list:
https://groups.google.com/forum/#!msg/edx-code/DmnHWmly25A/ZqjD1zb4o7oJ

And this thread contains another description of the changes:
https://groups.google.com/d/msg/edx-code/6dP9SEKsmqQ/Pvyn8fBDx68J

There are a numerous non-covered lines, all of which are missing
coverage in the CMS API this was ported from. They're mostly error
conditions, such as handling of multipart file upload errors.

ECOM-1734