ドキュメントには、
https://docs.microsoft.com/ja-jp/dotnet/api/system.net.http.httpclient.timeout?view=net-5.0

また、タスクで を使用して、個々の要求に対して異なるタイムアウト CancellationTokenSource を設定できます。

（日本語がおかしいのはご愛敬）

とあります。

また、サンプルコードとして以下の物があります。
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/cancel-async-tasks-after-a-period-of-time#complete-example

サンプルコード中では、ループ内で CancellationTokenSource を使い回していますが CancellationTokenSource 自体はリクエスト毎に都度使い捨てで問題ないかと思います。

C# 的にこれがベストな方法かは判断が付きかねますが、実装の一案ではありそうです。

（一度接続したら）Timeoutのような一部の設定は変更できない（コネクションプールを保持しているから？）

こちらについては以下の様な記述があります。
現実的には別スレッドで動作中だったり、 Keepalive 等でコネクション自体が繋がったまま変更されるのを防ぎたいなどの理由を推測します。

未処理の HttpClient 要求がある間は、のプロパティを変更しないでください。これはスレッドセーフではないためです。

個人的には RequestHeader や Timeout の値が異なる少数の HttpClient を保持する分には許容されるのでは無いかと考えますが、こちらは識者の意見が欲しい所です。

これについては段階的に直していきます。
まずはusingを止めて、各ServiceでHttpClientを1つだけ持つようにします（ #714 ）。

まずは現時点で分かっていることとして、現在の実装では using で毎回廃棄しているので、都度disposeされる。disposeされるとコネクションプールのソケットは閉じられるという認識で、今回のアプリを仮に配信したとして、すぐにソケットを枯渇させると言うことはなさそうです。

一方、コネクションプールの廃棄はとてもコストの高い処理になりますので、現在のdevelopの実装がイケてない、非効率的なものという点で修正の優先順位は高いです（この実装でリリースはしない）。

根本的にはHttpClientServiceから各Serviceに必要な設定のHttpClientを割り振る予定です。
もしHttpClientのインスタンスが1つにできるならそれが理想で、HTTP Headerや、タイムアウトの時間を設定する関係でHttpClientインスタンスそのものを分ける必要がある。分けた方が合理的となればそうしようと考えています。

このIssueはOpenのままにしておくので、なにか知見があればお寄せいただければ。

これについては段階的に直していきます。

御意。
HttpClient を多用するアプリではないので、ただちに問題になることは無いだろうと言う認識です。
とは言え何かの切っ掛けで問題のトリガーになりかねないので早めに改善しておきたいですね。

現在の実装では using で毎回廃棄しているので、都度disposeされる。disposeされるとコネクションプールのソケットは閉じられるという認識

情報共有の為に記述しておきます。

HttpClient の dispose で TCP/IP のソケットは解放されることが期待されます。
ただし、実際にどのタイミングで解放されるかはOSのTCP/IPスタックの実装依存で、 Windows 等だと数分間 TIME_WAIT と言う状態で残っているのはよく見かけます。（ .NET に限らない ）
Android / iOS で具体的にどのように扱われるかは分からないのですが。

またクライアントリソースの問題だけで無く、ファイヤーウォールやNAPTのセッション上限に達する可能性もありますので、問題が発生すると原因にたどり着くのが困難になることも想定されます。

杞憂であるとは考えていますが、そう言うこともあり得ると言う事は覚えておいて戴きたいかなと思いました。

やっぱり、Singletonなサービスにタイプ別のHttpClientを３つくらい保持して、それぞれのサービスから使う。ってのが一番良さそうですね。

Singletonなサービスにタイプ別のHttpClientを３つくらい保持して、それぞれのサービスから使う。

はい。現状では無難な解決法だと思います。

補足として、MS的には IHttpClientFactory を利用する事を推奨しているようです。
https://docs.microsoft.com/ja-jp/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

実際試している人の記事を見るとパフォーマンスも含めて良好な様子。
https://www.kinakomotitti.net/entry/2021/04/03/164718

ただ、これはこれできちんと調べないと罠がありそうなので、今後の課題かなと言う印象です。

#938 にも関わるので、これやります。