The mobile app is getting unexpected 403s from
/oauth2/exchange_access_token/, but we have been unable
to pinpoint from where they are coming. This commit
introduces a temporary exception handler to provide stack info
for 403s on this endpoint to try to track down the source.

Requires the ENABLE_403_MONITORING setting to be set to
True to enable the logging.

ARCHBOM-1667

[TSD] add annotations for login failure settings and feature flags

fix: Correct logging message to match function

[TSD] add annotation for the header & footer language selector

The logging text was duplicated from a different function

[TSD] Annotate schedules debugging toggle

feat: allow notify_credentials to take a list of usernames

[TSD] Annotate comprehensive theming settings

AA-511: update dashboard certificate button styling

docs: added related settings description for login attempts

Python Requirements Update

Bump version of edx-proctoring library to 3.4.0 to add interstitial for ready to resume state.

This release adds an interstitial in the proctored exam experience for learners with exam attempts in the ready_to_resume state, impacting Learners.

[MST-572] Add onboarding status view to instructor dashboard

[TSD] add annotations for ENABLE_HTML_XBLOCK_STUDENT_VIEW_DATA feature flag

test: Don't add a delta to ensure we get rate limited.

* Commits:
  style: Add more type-hints to discussions app

Mobile apps load HTML (and other) XBlocks individually using the
render_xblock endpoint. This is an attmept to reduce the number
of requests and JS processing needed to do so by detecting when
we have math content in HTMLBlocks and only adding the Mathjax
resources when necessary.

This is controlled by the "courseware.optimized_render_xblock"
CourseWaffleFlag. For maximum safety, we currently only optimize
in this way when directly hitting HTMLBlocks, and not for
ProblemBlock or VerticalBlock.

This was made as part of edX's Hackathon XXV.

The rate limiting library computes the rate limit by chunking time since
the epoch into chunks of whatever your period is. It then adds some
consistent offset based on your key.  This means that at certain times,
you are closer to the end of your rate limit time period than others.
So moving 1 minute into the future would put you into the next time
chunk and your rate limit would be reset.

I updated the test to test rate limit at the same time as the initial
call to ensure that we don't end up on the other side of a time chunk
boundary by accident.  We were seeing times in CI where it
would occasionally fail because time chunking wasn't in our favor.

feat: Update the user_authn app to not log PII by default.

updated for quality

[TSD] Annotate git export settings and toggles in CMS

* Commits:
  fix: Add DiscussionsConfiguration.enabled to admin page

* Commits:
  style: Cleanup DiscussionsConfiguration.__str__

Instead of optionally not logging usernames and emails, do so by
default.  This mostly removes some complexity from the app and is makes
it so that it's more secure by default.

I considered the question of allowing people to log usernames and
e-mails if they wanted to but opted not to for a couple of reasons:

* It would involve adding a new feature flag that would be the opposite
of the SQUELCH_PII_IN_LOGS which would be a bit confusing.  When do you
use which one? or do you need both? etc.
* There is still a way to correlate the messages to eachother and in
most cases also to a specific user(email being the exception).

Lower the pylint threshold to 200