feat(backend): 各種APIエンドポイントでレートリミットにあたったときRetry-Afterヘッダーを返してほしい

[KisaragiEffective]

Summary

各種APIエンドポイントでレートリミットにあたったときRetry-Afterヘッダーを返してほしい
related: #4838

Purpose

現状Retry-Afterがなければレートリミットを確かめることができるエンドポイントも無いため、実際にAPIへのリクエストが通るか、あるいは429で拒否されるかはリクエストを投げてみるまでわからない。
しかし、実際にリクエストを投げると大抵¹は429がまた帰ってくる。
これはクライアントにとってもサーバーにとっても余計なHTTPコネクションをハンドルしなければならなくなるため、よくない。

そこで、レートリミットが発動した際は次にレートリミットがリセットされる時点までの期間を秒単位に切り上げてRetry-Afterヘッダから報告することを提案する。

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

Footnotes

1. これはクリップにノートを追加するときやスレッドをミュートする時に顕著である ↩

[kakkokari-gtyih]

レートリミットの詳細を公開することにより不都合があるとどこかで誰かが言っていたような気がする
（#4838 にはなかったので気のせいかもしれない）

[KisaragiEffective]

note to myself:

• 一部のエンドポイントは固有のレートリミット(?)を持つ。
  • そのようなエンドポイントはpackages/backend/src/server/api/endpoints下でexport const meta\s*=\s*\{([^{]|\n)*limitを使うことで検索することができる。ここで出てきたlimitはレートリミットのウィンドウがリセットされるまでの時間である。
• ファクターは二つの要素に使われる。
  • 一つは次にリセットされるまでの時間に乗算され、結果として100%以上のファクターはデフォルトよりレートリミットのウィンドウを長くして、100%以下のファクターは短くする。
  • もう一つは最大回数の除算に使われる。結果として100%以上のファクターはデフォルトより呼び出し回数を少なくし、100%以下のファクターは長くする。
• 一部のエンドポイントは二次レートリミットを持つ。
  • そのようなエンドポイントはminIntervalというプロパティをpackages/backend/src/server/api/endpoints下のファイル内のmetaで持っている。
  • これらのエンドポイントは最小呼び出し間隔よりも短い間隔での呼び出しを拒絶する。次に、他のレートリミットを持つエンドポイントと同様に一般レートリミットのウィンドウ内で呼び出し回数が制限よりも多ければ拒絶する。