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.65724% with 117 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.63%. Comparing base (4bc0026) to head (7dd6fe8).
⚠️ Report is 125 commits behind head on develop.

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 ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #16932      +/-   ##
===========================================
+ Coverage    63.58%   63.63%   +0.04%     
===========================================
  Files         1156     1157       +1     
  Lines       115374   115576     +202     
  Branches      8152     8171      +19     
===========================================
+ Hits         73365    73546     +181     
- Misses       39827    39848      +21     
  Partials      2182     2182              

☔ 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	310.65 MB	317.08 MB	6.42 MB (2.06%)

See workflow logs for details

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消