fix(backend): WebSocketからの更新時にロックダウン設定が一切適用されない問題を修正

[kakkokari-gtyih]

What

WebSocketからの更新時にノートの内容を隠す設定が機能していない問題を修正

• NoteEntityService.hideNote を shouldHideNote と hideNote に分割
• NoteEntityService.shouldHideNote が呼ばれることが増えるため、Redisキャッシュを読むように（TODOの解消）
• ストリーミング時のロックダウンノート処理が共通で大きいため、別のServiceに分離して共通化

Why

ロックダウン設定が貫通する問題を修正するため

Additional info (optional)

基本的にロックダウンの時限設定を「n秒後」のような極端な数値にしたり未来の時刻にしたり（ #15198 ）といったケースはごくまれなので今までキャッチされてなかった説

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

❌ Patch coverage is 58.13953% with 126 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.84%. Comparing base (e0b872d) to head (33191ff).

Files with missing lines	Patch %	Lines
.../server/api/stream/NoteStreamingLockdownService.ts	40.31%	77 Missing ⚠️
...ges/backend/src/core/entities/NoteEntityService.ts	11.11%	40 Missing ⚠️
.../backend/src/server/api/stream/channels/antenna.ts	94.11%	1 Missing ⚠️
.../backend/src/server/api/stream/channels/channel.ts	92.30%	1 Missing ⚠️
.../src/server/api/stream/channels/global-timeline.ts	92.30%	1 Missing ⚠️
.../backend/src/server/api/stream/channels/hashtag.ts	92.30%	1 Missing ⚠️
...nd/src/server/api/stream/channels/home-timeline.ts	92.30%	1 Missing ⚠️
.../src/server/api/stream/channels/hybrid-timeline.ts	92.30%	1 Missing ⚠️
...d/src/server/api/stream/channels/local-timeline.ts	92.30%	1 Missing ⚠️
...nd/src/server/api/stream/channels/role-timeline.ts	94.11%	1 Missing ⚠️
... and 1 more

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #16932      +/-   ##
===========================================
+ Coverage    62.83%   62.84%   +0.01%     
===========================================
  Files         1150     1151       +1     
  Lines       115228   115448     +220     
  Branches      7892     7896       +4     
===========================================
+ Hits         72400    72554     +154     
- Misses       40668    40734      +66     
  Partials      2160     2160              

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

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

[syuilo]

• どのようなシチュエーションで再現できるものかしら
• どれくらいそういったシチュエーションが発生するかにもよるけど、追加で発生するコストと得られるメリットが見合ってないかも？
  • ロックダウンは簡易的なもので完全に隠せる訳ではない点は機能説明にもあるし、コストよりも厳密性を追求するといった機能ではない認識

[kakkokari-gtyih]

• 投稿時点でロックダウン対象の場合（これは本人の設定によるけどごくまれ）

に加えて、

• ロックダウン対象のノートをリノートした場合
• ロックダウン対象のノートを引用した場合
• ロックダウン対象のノートを引用したノートをリノートした場合

においても内容が隠れないので、影響範囲はそこそこ大きい（割と遭遇しやすい）と考えられる

[syuilo]

ロックダウン対象のノートをリノートした場合
ロックダウン対象のノートを引用した場合
ロックダウン対象のノートを引用したノートをリノートした場合

ロックダウン対象のノートをリノートは普通できなさそうな気がする

[kakkokari-gtyih]

少なくとも本人ならできそう

[kakkokari-gtyih]

少なくとも本人ならできそう

↑ のケース（ロックダウン対象になっているノートやその引用を本人がリノート/引用）は本人が意識せず行う可能性がありそうなのでしばしば発生しうる問題だと考えられる（このようなケースもAPI側ではハンドリングできているので、WSで来たのは隠れておらず、リロードしてAPIから取れれば隠れるという具合に挙動の不一致が露骨に出る）

じゃあロックダウン対象のものは一律でリノートや引用ができないようにすればいいのではないか？と思われるかもしれないが、そうするとフロントエンド/バックエンド双方でさらに条件が複雑怪奇になりメンテナンスコストや条件漏れのリスクが増大する（＝バグや意図しない挙動の温床になる）のでやるべきではない

shouldHideNoteが呼び出されることが多くなるのはそうなので、それに関してはフォロー関係をいちいちDBに取りに行くのではなくRedis Cacheを使用するようにすることで負荷軽減をねらっている（実際これを先行適用したサーバーではDBを含め負荷に有意な差はみられていないという報告を得ている）

[github-actions]

Backend Memory Usage Comparison

Metric	base	head	Diff
RSS	352.29 MB	359.66 MB	7.37 MB (2.09%)

See workflow logs for details

[kakkokari-gtyih]

コンフリクト解消