[TSD] Added annotation for ALLOW_HIDING_DISCUSSION_TAB feature flag

The Studio UI prevents you from creating a Section or Subsection
with no title (display_name). But OLX import allows you to bypass
these checks and create Sections ("chapter" tag) and Subsections
("sequential" tag) without display_name information specified in
the XML. When this happens, Studio and the LMS fall back to using
the url_name (the last part of the UsageKey) as a title, using the
display_name_with_default method.

This usually works, because url_names are derived from the import
file name, and if you're hand-editing a course in XML, your file
names are probably more intelligible than Mongo object IDs. In any
case, this commit updates get_outline_from_modulestore to match the
behavior of Studio and the LMS with respect to this situation.

This is part of the course outlines backfill rollout. TNL-8056

* Commits:
  feat: Add discussions API endpoint [BD-03]
  docs: Add ADR for DiscussionsConfiguration HTTP API [BD-03]

Co-authored-by: SaadYousaf <saadyousaf@A006-00314.local>

[TSD] Annotate relative_dates waffle flag

* Add toggle and settings annotations for CCX

Co-authored-by: Robert Raposa <rraposa@edx.org>

exp: Add logging to course cert availability date

I believe there to be a race condition here that only manifests in a
non-devstack environment. Adding some logging to better diagnose.

Reverts #26731

The code in common/lib/capa/capa/safe_exec needs
to remain Python 3.5-compatible, since edx-sandbox
(ie codejail) is still running Python 3.5.

AA-513: Reset segment state if anon user and there is a segment user id

[TSD] add annotations for ENABLE_DISCUSSION_HOME_PANEL feature flag

Update edX-hosted video player to use 2x playback speed

This will make it possible to make a New Relic dashboard for the
learning_sequences API calls that tracks call performance across
different transactions (by querying Spans). Our goal would be to
offer SLAs around 99th percentile performance.

Course IDs and User ID metrics are also added, so that we can see
outliers in Span reporting, for later investigation.

LEARNER-8247

Co-Authored-By: Sarina Canelake <sarina@edx.org>

* added iframe mfe overrides

* Added import to rtl

* Refactored

* Added comment

MICROBA-1025 | Update cert_whitelist management command

* refactor: pyupgrade in common/lib/xmodule

Co-authored-by: Usama Sadiq <usama.sadiq@arbisoft.com>

* refactor: pyupgrade on common/lib

Co-authored-by: Usama Sadiq <usama.sadiq@arbisoft.com>

pyupgrade in calendar-sync. 

= IMPORTANT WARNING =

This can be a VERY EXPENSIVE MIGRATION which may take hours or
days to run depending on the size of the courseware_studentmodule
table on your site. Depending on your database, it may also lock
this table, causing courseware to be non-functional during that
time.

If you want to run this migration manually in a more controlled
way (separate from your release pipeline), the SQL needed is:

  CREATE INDEX `courseware_stats` ON `courseware_studentmodule`
     (`module_id`, `grade`, `student_id`);

You can then fake the migration:
  https://docs.djangoproject.com/en/2.2/ref/django-admin/#cmdoption-migrate-fake

= Motivation and Background =

TLDR: This adds an index that will speed up reports like the
Problem Grade Report. This fixes a performance regression that
was unintentionally introduced in 25da206c.

I'm capturing the entire saga below, in case Open edX operators
need to dig into it.

The tale begins in November of 2012 (yes, seriously). We had an
inline analytics feature that would display a histogram to course
staff by each problem in the LMS, detailing how students did on
that problem (e.g. 80% got 2 points, 10% got 1 point, 10% got 0
points). The courseware_studentmodule table already had an index
on the module_id (a.k.a. module_state_key), but because there
were 100K+ students that had student state for some problems,
the generation of those histograms was still extremely expensive.
During U.S. Thanksgiving weekend in late November of 2012, that
load started causing operational failures on edx.org.

As an emergency measure, I manually added a composite index for
(module_id, grade, student_id) on courseware_studentmodule in
order to stabilize the courseware on edx.org. I did _not_ follow
up properly and add it in a migration file. Later on, the inline
analytics feature was removed entirely, so the index was considered
redundant (but again, it was not properly cleaned up).

Various reports were created over the years, some of which
relied on having an index for module_id. These ran fine because
there had long been an index for that field specifically.

In 2018, the courseware_studentmodule table for edx.org ran into
the 2 TB size limit that our old RDS instance had. We had a fair
amount of monitoring for various limits that we thought we might
run into, but the per-table limit took us by surprise. The Devops/
SRE person fielding that issue needed to free up space in a hurry
in order to make the courseware functional again. Examining the
database itself, he noticed that we had a module_id index that was
technically redundant because the composite index of (module_id,
grade, student_id) would cover queries that would otherwise use it.
Again, as an emergency measure, he dropped the index on module_id
in order to free up a little space and buy enough time to do a
proper move of the database to Aurora.

Devops-of-2018 being more disciplined than me-of-2012, the index
on module_id was removed in 25da206c. The intention was to make it
so that the state of the code would match what was live on edx.org.
But because the composite index was added in an ad hoc way, what
that really meant was that now queries involving module_id were
_only_ indexed by the (module_id, grade, student_id) composite
index that existed only on edx.org and no other Open edX instances.

We didn't realize this issue until months later. @blarghmatey
created an index to re-add the index for module_id:

  https://github.com/edx/edx-platform/pull/20885

The reason why we didn't accept this immediately is because
migrations for this table are very operationally risky and take
days to run. Faking this migration would have put edx.org even
more out of sync with the Open edX repo. Complicating this
somewhat was the fact that some folks still seem to be running a
variant of the inline analytics on their fork.

So in the end, we're going forward with this migration that brings
the code fully into sync with indexes on edx.org and covers the
obscure inline analytics histogram use case, while still covering
the module_id index needed for the fast generation of certain
reports that focus on a single problem.

Sorry folks.

Fix button/title text

If we are seeing an anonymous user, but the segment user id is still
set, we believe the segment user id is coming from a different user on
the same machine. This will make sure we clear out that storage and
then the indentify call will make a new anonymous id

1) Account activation email.
2) Password reset email.
3) Password reset success.

VAN-272

[MICROBA-1025]
- Update management command to use the same logic that the Instructor Dashboard uses
- Fix bug in management command where processing stopped when encountering a user that did not exist
- Add more logging
- Add and update tests where needed

Pin diff-cover to fix tests on Ubuntu 20.04

In commit 9b37e7d0, the logic of
`streak_celebration_is_active` was accidentally
changed such that it no longer checks the
Progress Milestones waffle flag.
This commit fixes that.

Note: This also adds in a transitive check to
`courseware_mfe_is_active`,
which makes sense for Streak Celebration
and should not have any functional impact.