When we introduced Markdown support, we had two renderers:

Python-Markdown (for the server side), and marked.js (for the client

side). Due to a number of issues in the marked.js rendering, this

resulted in some unsatisfactory rendered output in certain situations,

and required invasive escaping to work around other issues.
We no longer use marked.js (which will be removed in a separate change).

Instead, Markdown is rendered as part of the page, and as part of any

API responses (by using the force-text-type options in API requests).

This improves the perceived load time of the page, gives us consistency

in rendering, and will allow us to be a lot smarter about how we escape

and process Markdown in the future.
Some behavior has changed along with this, which should help fix cases

reported by users:
* Code blocks without a language identifier are no longer highlighted by

  default, meaning that fenced or idented code blocks can now be used

  for any plain text.
Unfortunately, this does mean that older text with code blocks will no

  longer be highlighted unless they use a language identifier on a

  fenced code block, but it's worth losing that to gain some

  consistency.
* Text in code blocks will no longer be turned into links, and will no

  longer be syntax-highlighted, making a plain fenced code block immune

  to formatting.
In order to have access to the raw data for the inlineEditors, builtin

fields now have their raw data stored in the reviewRequestData for the

page, and custom fields have their raw data stored as data-raw-value=

attributes (which are then stored in extraData and removed from the

DOM on load).
This change should let us resolve a lot of the issues people have hit,

and provides a stepping stone for proper support for disabling Markdown

for a field.

Tested editing every type of field on a review request (including

custom ones), every type of comment, and replies to reviews.
This has not yet been tested with top-level comments or reviews,

since those are only ever rendered on-the-fly on master with the new

Review dialog. Separate changes will be made there to fix that up.
Tested these with and without rich_text=true in the database.
Tried adding code blocks using indentation, fences, and fences with

language IDs. Saw that only the ones with language IDs had any

highlighting.
Added various types of Markdown formatting and linkage to code blocks,

and saw that they never linked.
Unit tests on JavaScript and Python pass.
While I've tried to be extensive in my testing, I really would greatly

appreciate having more people go through and test every condition in

order to make sure I didn't miss something important.