fix(backend): リプライがstreamで配信される際にリプライ元のmyReactionが正常に配信されていない問題を修正

[kakkokari-gtyih]

Todo: https://activitypub.software/TransFem-org/Sharkey/-/merge_requests/840

What

リプライとその被リプライのノートがstreamに流れる際に、被リプライのノートにmyReactionがある（＝被リプライのノートに自分がリアクションしている）場合でもそれが正常に反映されていない問題を修正

↑青色の枠で囲ったノートがstreamで流れてきた際に、赤色の枠で囲ったほうのリアクションにmyReactionがあった場合でも正常に記録されていないという問題があった

Why

Additional info (optional)

Misskeyの標準UIでは被リプライのノートのリアクションは最小化されて表示されないので今まで影響がなかった

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Add story of storybook
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 39.94%. Comparing base (4120c9a) to head (543aa5a).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop   #15210   +/-   ##
========================================
  Coverage    39.93%   39.94%           
========================================
  Files         1563     1563           
  Lines       197977   198016   +39     
  Branches      3633     3628    -5     
========================================
+ Hits         79065    79097   +32     
- Misses      118307   118346   +39     
+ Partials       605      573   -32     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

このPRによるapi.jsonの差分
差分はありません。
Get diff files from Workflow Page

[dakkar]

please do NOT merge this yet

we have discovered a bug.

the source of the problem is that StreamingApiServerService creates a single EventEmitter per server process https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/server/api/StreamingApiServerService.ts#L115

so when a note is published to redis, it gets de-serialised once per server process, and then that single objecc is passed to all active channels on each connection.

so for example, if we had a single web server process:

• user A is looking at a timeline
• user B is looking at a timeline, doesn't matter if it's the same kind or not
• a note arrives, that is visible to both users
• the onNote of the channel attached to the websocket connection of user A sets the myReaction inside the note, asynchronously
• the onNote of user B does the same, assigning a different value inside the same object
• these two operations can happen in any order, before each onNote does the send at the end
• so the frontend can receive a note with the wrong myReaction

this was not a problem before these changes, because each onNote did a single await before the assignment, then did the send immediately; now, with more promises/await involved, things break

we're working on a fix (which will probably involve a doing shallow clone of the note object before modifying it), I'll link to our branch as soon as we've tested it