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

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.

This is an initial authentication implementation that allows LTI users to
log in transparently to edX. The behavior is driven by pilot users at
Harvard; this was the most requested feature.

The patch creates a new database model that maps users' LTI identifiers
to newly-created edX accounts. If an LTI launch comes in with a user_id
field that is not in the database, a new edX account is created with a
random user name and password. This account is then stored in the
database, so that it is permanently associated with the LTI user ID.

This patch takes a simplistic approach to session management. If a user
is logged in with a different account when they perform an LTI launch,
they will be logged out and then re-logged in using their LTI account.

In order to keep the patch simple, I have split out some refactoring
that needs to be done into a separate branch that I'll post once this
has been merged. Since we no longer redirect to the login page, we don't
need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that
requires. There are also multiple fetches of the LtiConsumer object
(one in the view, one in the signature validation) that the later
patch will consolidate into one.

This branch fixes the previous conflicts with the test refactoring
carried out in PR 8240.

Change https://github.com/edx/edx-platform/pull/8240 refactored the LTI
provider template rendering code and introduced an issue where a user was
required to be enrolled in a course before that course's content could be
accessed over LTI. According to the LTI design spec:
    https://docs.google.com/document/d/185hdPvIxcKtiDOLjb4sTGovA_WYXWz5Cd79gCzQwBms
we delegate access control over LTI content to the LTI consumer, rather
than requiring that users enroll in edX courses explicitly (and that admins
keep edX and LTI provider enrollemnts consistent when students add or drop
courses).

This change fixes the immediate issue, which is disrupting the LTI Provider
pilot currently running at Harvard.

This change cleans up the work in progress request at https://github.com/edx/edx-platform/pull/8176

This is an initial authentication implementation that allows LTI users to log in transparently to
edX. The behavior is driven by pilot users at Harvard; this was the most requested feature.

The patch creates a new database model that maps users' LTI identifiers to newly-created edX
accounts. If an LTI launch comes in with a user_id field that is not in the database, a new edX
account is created with a random user name and password. This account is then stored in the database,
so that it is permanently associated with the LTI user ID.

This patch takes a simplistic approach to session management. If a user is logged in with a
different account when they perform an LTI launch, they will be logged out and then re-logged
in using their LTI account.

In order to keep the patch simple, I have split out some refactoring that needs to be done into
a separate branch that I'll post once this has been merged. Since we no longer redirect to the
login page, we don't need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that requires. There are
also multiple fetches of the LtiConsumer object (one in the view, one in the signature
validation) that the later patch will consolidate into one.

The line below was left in during the refactoring shuffle from PR #8205, and causes
an issue in a corner case where an LTI launch provides an instance GUID where there
wasn't one already set for the consumer. This change fixes the bug, and adds a test
to prevent it from recurring.

This change allows the LTI provider to pass grades back to the campus LMS platform using the
LTI outcome service. For full details of the outcome service, see:
    http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html

In brief, the LTI 1.1 spec defines an outcome service that can be offered by an LTI consumer.
The consumer determines whether a score should be returned (in Canvas, this means that the LTI
tool is used in an assignment, and the launch was performed by a student). If so, it sends
two additional parameters along with the LTI launch:

lis_outcome_service_url: the endpoint for the outcome service on the consumer;
lis_result_sourcedid: a unique identifier for the row in the gradebook (i.e. the tool/student/assignment combination).

The LTI Provider launch view detects the presence of these optional fields, and creates database
records for the specific Outcome Service and for the graded LTI launch. Later, when a score on
edX changes (identified using the signal mechanism from previous LTI Provider pull requests),
a Celery task is launched to pass the score back to the LTI consumer.

Updated LTI render courseware test for courseware-chromeless.html