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 src/lib/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
• 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)
    • Side note: This seems to be more or less the approach proposed here by @akhmerov in 2022
  • 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._.mathjax namespace. While not officially documented, the pattern is used in several places (one, two, three) in the MathJax docs for advanced configuration
    • The MathJax API is mainly intended for rendering entire documents/pages in one shot, so it doesn't directly expose functions for rendering individual expressions one-at-a-time
  • 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
  • Exception: In the mathjax3__mathjax mock, the pie labels which were previously hidden, are now visible as raw MathJax. We don't support rendering MathJax in pie labels. Now at least the behavior is consistent between v3 and v4. However we could change the behavior to hide MathJax text strings in places where we don't support rendering MathJax.
• 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
  • This includes some updates to the MathJax devtools dashboard homepages

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 us not supporting MathJax in pie labels; this is not new, and it's (somewhat) deliberate, to lock in 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

[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.

[emilykl]

Note: this addition fixes a bug where MathJax expressions would not render larger than font size 16 in plotly