I think I have discovered another breaking change that you didn't mention, though it is probably super-niche.
This commit: https://github.com/NodeBB/NodeBB/commit/ec91ef1c644044bba44198b031913655e784b4bb
broke our custom SSO plugin. The result was that after successfully logging in our external identity provider and being redirected to our Forum's callback endpoint, I was ending up not logged in (the button in the header still said "Log in") and stuck on /register/complete roadblock. It looked like our Passport strategy verify callback, that parses output from the identity provider and fetches user data via OAuth2 was not invoked at all.
It turns out that the changes in this commit don't play well together with passport-oauth2 (https://github.com/jaredhanson/passport-oauth2) internal ability to protect against CSRF (which we were using). This strategy was already using state parameter to pass its own CSRF token. I don't have more time to investigate but I suspect things shipwrecked when NodeBB overwrote the state parameter with its own CSRF token.
Turning off passport-oauth2 internal CSRF protection (by removing state: true from its options) fixed the issue.
This is due to older socket.io clients (running on version 2) attempting to connect to the new socket.io 3. These protocols are incompatible, and so the connection is rejected, and NodeBB was configured to try indefinitely.
This is ok. Over time, as your users close their browser windows (or refresh), they will automatically start using the latest version, and socket usage will return to normal levels.
If you are worried about the excessive traffic, you can configure a nginx condition to drop requests with the query string ?EIO=3. Please see the issue linked above for more information.