[#3111] fix markdown rendering applying before mathjax rendering

[AndreaBarbasso]

References

• Fixes Rendering markdown before mathjax can lead to wrong outcome #3111

Description

With this PR, LaTeX formulas are rendered with mathjax before any markdown rendering is applied. This fixes unwanted behaviors described on the linked issue.

Instructions for Reviewers

List of changes in this PR:

• Applied mathjax rendering before markdown rendering (if mathjax is enabled);
• Removed nativeWindow injection in client-math.service (since it's a Client-Side-Rendering service, there is no need to use the injection);
• Included the popular LaTeX $$ delimiter in the list of approved delimiters.

To test this PR, try to use this text in any place where the markdown rendering is enabled:
...measurements in (EDT-TTF-CONH$_2$)$_2^{+}$[BABCO$^{-}$] (EDT-BCO) confirmed the absence....
It should render fine, instead of showing a broken formula and some italic text.

Checklist

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using yarn lint
• My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[kshepherd]

+1 thanks @AndreaBarbasso ! I have tested with and without this functionality and can reproduce the problem and confirm the fix. The code changes all look good to me.

[dspace-bot]

Backport failed for dspace-7_x, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin dspace-7_x
git worktree add -d .worktree/backport-3112-to-dspace-7_x origin/dspace-7_x
cd .worktree/backport-3112-to-dspace-7_x
git switch --create backport-3112-to-dspace-7_x
git cherry-pick -x 66e1a2488b14c84b41486fabc77350f17d722b0d

[dspace-bot]

Successfully created backport PR for dspace-8_x:

• [Port dspace-8_x] [#3111] fix markdown rendering applying before mathjax rendering #3218

[kshepherd]

@AndreaBarbasso @tdonohue i realised after merging that the 7.x backport will have to be done quite manually - the services and components used in mathjax rendering appear to be quite different compared to 8.x+
So this won't be just a cherry-pick with conflict resolution to backport. @AndreaBarbasso is that something you already have, or had planned to do? Should we only backport to 8.x?

[tdonohue]

@kshepherd and @AndreaBarbasso : Per our Support Policy, we only guarantee bug fixes to the most recent major release (currently 8.x). So, that means we require bug-fix backporting to 8.x (where possible to do so), but bug-fix backports to 7.x are optional, unless it's a serious bug/security issue. That said, I've been making a "best effort" to try and backport things to 7.x where it's "reasonable to do so", just because so many sites are still on 7.x.

So, this is all to say that I'd also welcome a 7.x backport, but it's not required.