fix: Replace RE2 with RegExp for "mute word" regex validation (resolves #850)

What does this MR do?

Replaces RE2 with RegExp in the validateMuteWordRegex function. This should allow the full range of regex features to be used, such as negative lookahead. For example, the word mute /test(?!osterone)/i should now no longer throw an error, and should match "test" but not "testosterone".

Previously, regex word mutes were limited by the RE2 implementation, to avoid expensive computation on the server side. However, according to @dakkar, this should no longer be necessary. See #850 (closed) for further details.

I've tested that negative lookahead functions properly with this change applied. I have not tested whether this change might open up a risk of malicious expressions with exponential runtime running on the server, since I couldn't find any usable examples. This MR assumes that @dakkar's conclusions in #850 (closed) were correct (and that I've interpreted them correctly.)

Contribution Guidelines

By submitting this merge request, you agree to follow our Contribution Guidelines

• I agree to follow this project's Contribution Guidelines
• I have made sure to test this merge request

for context:

• in the backend, re2 is used in 3 places: the i/update endpoint that this MR changes, UtilityService.isKeyWordIncluded and checkWordMute
• isKeyWordIncluded is only ever called for meta.sensitiveWords or meta.prohibitedWordsForNameOfUser
• checkWordMute (the backend version) is not used at all (the only mentions are inside its own unit test file)
• all other regex checks are run with RegExp (mostly in the frontend)

so I believe this change is safe

approved this merge request

I just thought of a vaguely-sensible reason to keep this restriction:

• if we extend antennas to use regexes instead of just substring
• then those regexes would have to be limited to re2 (because they would run in the backend)
• and having some regexes limited to re2 and some not, may be confusing to users

I'm not sure "there may be confusion in the future" is a good enough reason…

added 13 commits

• 9160ede4...5eca807e - 12 commits from branch TransFem-org:develop
• 5fafc1a6 - Merge branch Sharkey:develop into develop

Compare with previous version

resolved all threads

added bugbackend label

approved this merge request

mentioned in commit 4b6a338e

merged