Upgrade RapidJSON

[ianthetechie]

Issue

Fixes #4050.

Tasklist

• Add tests
• Add #fixes with the issue number that this PR addresses
• Update the docs with any new request parameters or changes to behavior described
• Update the changelog
• If you made changes to the lua files, update the taginfo too.

[ianthetechie]

This does not currently add any new tests, but it does fix UB in an existing test. We are currently permissive in our sanitized runs and do not throw an error.

I would suggest building with -fno-sanitize-recover eventually as the "test case" after #4049 is addressed.

[nilsnolde]

Always a tough decision when a project isn't releasing anymore.. 7 years and counting.. Though the project is far from being dead apparently. @mloskot summarizes it well 😄

Since there's maintenance going on, I'd personally be in favor of upgrading to the latest commit, seeing how we're vendoring it anyways (plus our own "test coverage" for rapidjson is quite high I'd say). Curiously they only seem to test windows though, never seen that on a C++ repo haha

[mloskot]

Apart from the generic "ain't broke, don't touch", I don't see any reason to not to upgrade

[kevinkreiser]

yeah i want to echo that sentiment from @mloskot

i feel like a lot of times people make too much of a big deal out of "unmaintained". the json spec itself reached its latest revision 5 years ago but has existed for like 20 years more or less. rapidjson, and many other projects like it, are small convenience libraries that do one job well. barring any bug fixes, what on earth else would "maintained" even signify? in summary, the library implements a spec which is mature for a long time and is narrowly focused on that point, i see no reason to worry at all about it being "unmaintained". ship it!