Refactor Golden Master spec approach for testing Gitlab-flavored Markdown support in the Content Editor

Problem to solve

Gitlab-Flavored Markdown (GFM) is large and has many edge cases to test. The Content Editor currently supports rendering some of the GFM content but we eventually need to support it all. If something is added to GFM, we need to have some kind of way to test our support against a Golden Master (GM) specification.

See the MR for details: !68671 (merged)

Scheduling Note

UPDATE: If we are considering changing to an independent frontend markdown renderer, which we are considering in order to better support source maps (TODO: add link), we should consider prioritizing this sooner than later, so we have our ideal test framework in place before we continue iterating and adding more markdown support.

Notes on Source Mapping

From Slack thread:

• Chad Woolley: @Enrique Follow up question from the meeting: What, if anything, in GitLab, consumes or uses the existing sourcemap metadata in the existing markdown HTML rendered from the C library?
• Enrique: @Chad Woolley we are using it for task lists. We use it to identify which line in a Markdown string should be modified when a task list item is checked or unchecked: app/services/task_list_toggle_service.rb:72
• Enrique: @bwalker is this correct?
• bwalker: That’s correct. It’s now also being used to allow us to create a new issue from a task, and intelligently replace that task with issue information. I do think there is another place that is non-task related, but I can’t pull it from memory right now 🤔
• bwalker: fyi, if you need to run specs that ignore sourcepos (because they can be verbose), you can pass no_sourcepos: true into the renderer, or use stub_commonmark_sourcepos_disabled

References

• Comments on !55856 (merged)
• #323766 (closed)