Upgrade MathJax support from v2/v3 to v3/v4

[emilykl]

Update plotly.js to be compatible with MathJax v4, and drop support for MathJax v2.

Due to some logic improvements, this should also make MathJax rendering faster.

• Modify svg_text_utils.js to use MathJax v3/v4 syntax to render math symbols
  • MathJax v3 and v4 use the same syntax, so we can get rid of the if/else cases we used to handle v2 and v3
  • MathJax v4 uses asynchronous rendering calls only, so a small amount of refactoring is required to handle the asynchronous renders
• Improve performance by not calling MathJax.startup.defaultReady() on every individual render. This was very slow and also not recommended usage of the MathJax API
  • Instead, create a secondary MathJax document upfront that we can use for our purposes, without affecting the page's main MathJax document, and call MathDocument.convert(tex) rather than MathJax.typeset(tex)
  • This also means we no longer have to reset the config after rendering, since the config is applied only to our internal MathJax document
  • This approach does involve three places where we reference functions/objects in the MathJax._. namespace. While not officially documented, the pattern is used in several places (one, two, three) in the MathJax documentation for advanced configuration
    • The context is that the MathJax API is really intended for rendering entire documents/pages in one shot, so it doesn't directly expose functions for rendering individual expressions one-at-a-time. I feel fine about this workaround though, given that it works in both v3 and v4
  • As a nice side effect, this change should make MathJax rendering in plotly much faster
• Update image baselines
  • There are visible differences, but no regressions; all the changes are minor typsetting differences in character spacing or line height, which makes sense for a new MathJax version
• Update all testing infrastructure to use MathJax v3 and v4 rather than v2 and v3.
  • NOTE: I've done this by changing all references to v2 to v4. This means that v4 is now the "default" in the CI, unless v3 is explicitly specified

Steps for testing

• Check out this branch
• Run the test dashboard (npm start) which uses MathJax 4
• Verify that every mock with mathjax in the name (and the other baselines changed here) looks OK and matches the new baselines on this branch
  • Note: The mathjax mock itself contains several strings of TeX which don't render due to syntax errors; this is not new, and it's deliberate, to test the fallback behavior
• Visit the MathJax 3 test dashboard (http://localhost:3000/devtools/test_dashboard/index-mathjax3.html) and verify again that everything looks fine

[emilykl]

add a TODO to investigate this further

[camdecoster]

Why is this call to handleRetriesFor required?

[emilykl]

Found a page in the docs which explains it: https://docs.mathjax.org/en/v4.0/web/retry.html

From what I understand, it sounds like MathJax dynamically loads some features/extensions only as needed, and the internal synchronous functions are designed to error out if a required feature is not available, with a wrapper function catching the failure, loading the required feature, then retrying the function. The wrapper function returns a Promise which resolves when the wrapped function eventually completes successfully.

handleRetriesFor() is that wrapper function.

.convert() is a synchronous function, so wrapping it inside handleRetriesFor() has the additional impact of turning the call to .convert() into an asynchronous function.

[camdecoster]

Should this be an async function?

[emilykl]

I believe since initiateMathJax() always returns a Promise, there's no programmatic reason to make it an async function (all that would achieve is making the function return a Promise, but it's doing that anyway).

I guess it wouldn't cause any problems to add async to the function definition, but I don't think we've done that anywhere else in the codebase.

[camdecoster]

Do you now why the legend got smaller?

[emilykl]

I don't know, but I did add a new mock mathjax-font-size to ensure that the rendered MathJax is picking up the font size of the original text.

Since that seems to be working, I think this change might just be a styling difference between MathJax v2 and v4.

[camdecoster]

Is the MathJax specifier supposed to be showing up in the pie chart? Is this the fallback behavior?

[emilykl]

@camdecoster I think I said something different in our call, but the actual reason why the raw MathJax string is showing up here because the library doesn't yet render MathJax for pie labels. So the entire rendering step is skipped and the string is shown as-is. (The exact same string is rendered 'correctly' in the legend to the right.)

The raw MathJax string shown here is present since the mathjax baseline image was first added to the repo. The fact that the string wasn't shown in the mathjax3__ version of the mock is the outlier. I'm pretty neutral on which behavior is more correct.