Fix text/rich text loading, rendering, and storage for custom fields.

Review Request #10103 — Created July 27, 2018 and submitted — Latest diff uploaded

Review Board

The rewrite of custom fields on the JavaScript side broke several
aspects of text-based fields, causing rendering glitches and bad data
stored in extra_data. The following issues were found:

  1. The registered field ID was often being used instead of the JSON
    field name, preventing some fields from being looked up in any

  2. Similarly, a <fieldID>RichText boolean was being looked up (and
    saved) for custom fields, instead of using the
    <json_field_id>_text_type value.

  3. These values were always being pulled out of extra_data, which
    resulted in corrupted displays, as we were requesting HTML renders of
    the values. raw_text_fields should have been used instead.

  4. The new dirty handling wasn't noticing changes to the Enable Markdown
    checkbox, due to race conditions in calculation.

Fields now have mandatory jsonFieldName and jsonTextTypeFieldName
(for text fields) attributes, which are guaranteed to be set. These are
used or provided wherever we may be working with extra_data or

setDraftField() and getDraftField() now assert for required values.
getDraftField() also now accepts some options for working with

Value loading for fields has been centralized in a _loadValue()
function, preventing some copy/paste for non-trivial calls. Same with
loading rich text booleans for text fields.

Unit tests have been introduced for custom fields to check all the
various states, preventing regressions in the future.

All unit tests pass.

Tested loading and saving both plain text and Markdown text for
all forms of built-in text fields (Close Description, Draft Change
Description, Description, Testing Done) and custom text fields.
Ensured that initial loads of both text types work, that saving
works, and that saving twice in one page session works.