LEARNER-1923

EDUCATOR-341

EDUCATOR-229

EDUCATOR-11

LEARNER-394

Ensure Enterprise-integrated courses require user consent before granting access to Wiki and Discussion forum.

* User-facing links are gated; internal services are not.
* Adds view decorator data_sharing_consent_required
* Renames `get_course_specific_consent_url` to `get_enterprise_consent_url`,
  which now checks `consent_needed_for_course` before returning a consent URL.

Firstly, we're now explicitly instructing the comments service to not
return thread responses/comments if the request isn't AJAX.  So, if you
load the URL for a single discussion thread in your browser, this would
be a non-AJAX call and we'll avoid loading the responses for the entire
thread behind-the-scenes.  Big win here for large threads.

Next, we removed a redundant "get threads" call which was also happening
behind-the-scenes.  This call was redundant as the front-end JS also
grabs the thread list when a topic is chosen, so we were making an
extranenous call for no benefit.  Poof, gone!

Finally, we added some caching of database queries that are required to
drive a lot of the permissions/cohorts machinery around discussion.
This will have a minimal effect but introduced a cleaner way to apply
general memoization at the per-request level which will let us further
cache things as we identify them as issues.

- Default of "desc" is all that is in use, and remains as-is.
- Discussion API keeps order_direction param, to minimize changes,
but it only accepts "desc".
- Discussion webapp simply no longer sends in the sort order.

We're often grabbing the metadata of a specific thread to then be able
to perform other operations, but we never need the actual responses or
comments of a thread unless we're displaying it in the normal forum
view.

This change sets a default of with_responses=False, which instructs the
comment service to not send back the responses/comments for the given
thread.  We only ask for responses in the case of rendering a single
thread or inline discussion.

* Renames discussion_module to discussion_xblock
* Moves common/lib/xmodule/xmodule_discussion to openedx/core/lib/xblock_builtin/xblock_discussion

TNL-4622

Revert "SUST-35 Implementation of course_key_from_string_or_404 to return course_key or raise a 404"

Revert "SUST-35 Implementation of course_key_from_string_or_404 to return course_key or raise a 404"

-Updated method "course_key_from_string_or_404" to raise message too.
-Wrote tests for "course_key_from_string_or_404" when exception message is given.
-Modified existing methods to use "ddt.data".
-Used Splunk logs to find exectly where we were getting "Invalid Key Error"
-Updated Views where we were getting "Invalid Key Error" in splunk logs.
-Wrote tests for those View End points where we were getting "Invalid Key Error"