When a self paced course was published and we were configured to
automatically space out due dates among its sections, we were
accidentally setting due dates on ungraded content. Which limited
access to it.

AA-162

remove useless-supression warnings - BOM-1353

CRI-196 Quiet deprecation warnings from imp and courseware modules

Fixes hidden tabs showing up in courseware MFE.

As it is explained in courseware/__init__.py:

    Importing 'lms.djangoapps.courseware' as 'courseware' is no longer
    supported

This warning, while relevant, decreased the signal/noise ratio when
investigating the lms logs.

The "bulk_email" app was the only remaining app importing the courseware
module incorrectly. All edx-platform modules and dependencies now follow
the new convention.

This is in part for CRI-196.

The "imp" module is deprecated and should be replaced by "importlib". As
a consequence, loading the django settings used to raise deprecation
warnings:

    DeprecationWarning: the imp module is deprecated in favour of
    importlib; see the module's documentation for alternative uses

It should be noted that python 3.5.1 ships with an older release of
distutils which still relies on the imp module. Thus, users of python
3.5.1 (for instance: edx.org developers) will continue to see the
deprecation warning for some time, despite this patch. We suggest
upgrading to python 3.5.9.

This addresses part of CRI-196.

In the case that that are order dependent failures on Jenkins, this
script can be used to automatically find the minimal set of tests
required to continue to test the failure locally.

Reduce upselling on Dates tab

The dates tab has a lot of redundant calls to action around
upgrading to verified track. This replaces them with a single
banner at the top of the page.

AA-102

Only show the resets date banner if you have missed the due date on a…

Refactors courseware metadata code.
Enables masquerading in the courseware metadata API.

[AA-138]

Cache Blockstore XBlock field data per thread, not per-process

REST API for managing Content Library bundle links

* fix get_worker_test_list.py

The test name is not always at the same index in the line, so pull
it from the regex instead.

PROD-1480

Also changed `password_reset` endpoint rate limit configuration to
1/minute from 30/5 minutes.

PROD-1427

It doesn't look like this setting was required, and because it didn't
use override_settings, it broke other tests.

* Commits:
  Stop skipping chromeless iframe resize onload event

in the case where the MutationObserver has already tried resizing the
iframe prior to it fully loading.

Python Requirements Update

TNL-7148 -- support external links in courseware API

Add support for external user ids to the xblock user service.

fix issue with is_in_memory_db

* Revert "Use pip-sync to make sure that dep cache tarball can go safely stale"

This reverts commit d435f4cd.

* Revert "Extract worker setup into own shell script, as much as possible"

This reverts commit 0a079e75.

This reverts commit be1aaa00.

For mysql, it seems `is_in_memory_db` does not even exist. Ensure it
exists before calling it.

These removed tests can be restored once someone works out why they
were causing flakiness elsewhere and fix the problem.

Reverts tests added in:
https://github.com/edx/edx-platform/commit/dca50aacc3093c29c830cccae5746247ecb6f02b

[SE-2264] [LX-744] Return more metadata in xblock api

The cache in the previous version of this code was unwittingly being
shared among all threads, and an occasional race condition would result
in the .children field of some XBlocks containing duplicate entries.

I tried to find other ways to keep the existing cache design and let it
be shared among all the threads (which would be more efficient), but I
couldn't find any clean way of doing it (and even then, this code was
not written with the intention of being used in a multi-threaded way).
So to keep the fix simple, I made the block data cache thread-local
instead of process-local. That eliminated the bug.

Technical details:

The big challenge with this code in the first place was due to the
parse_xml API of XBlocks, which instantiates the XBlock instance and
_then_ sets field data on it and returns it, as there is no mechanism
available to distinguish that from the case of instantiating an XBlock
(using previously loaded/cached field data) and then deliberately
changing its field values. In particular, parse_xml sets the 'children'
field just by calling self.children.append(...) but never explicitly
initializes self.children to [] first, so it's necessary for the field
data store to have a mechanism for setting self.children = [] when
parsing begins, but it's hard to know "when parsing begins" in general.

This is made more challenging since the BlockstoreFieldData design ties
field data changes to the XBlock instance itself (using a weakkey), but
it's impossible to get a reference to the XBlock instance before calling
parse_xml, and since the BlockstoreFieldData design uses a pass-through
approach where fields that aren't being actively changed are read from
the cache; since it doesn't know when children is being initialized vs.
being modified, it would sometimes pass-through and start one thread's
changes with the final result from another thread.

Anyhow, the bottom line is that avoiding unintentional multithreading
here solves the problem.

If we want the field data cache to be shared among threads, it might as
well be rewritten to use memcached and shared among all processes too.
That would be a very good performance boost but would take up a lot more
memory in memcached. Also the rewrite may be challenging due to the
aforementioned nuances of the XBlock parse_xml / construct_xblock /
add_node_as_child APIs. Perhaps modifying the runtime to use a
completely separate fielddata implementation for parsing vs. loading a
parsed+cached XBlock would do it.

* Commits:
  Add logging to Learning MFE iframe, temporarily