Api: order paging surface 丢弃了总计数,没有迭代器,从研究上来看很难使用

（a） 总订单数量已被获取，然后被丢弃 `OrdersResponseWrapper` 承载了它，文档注释中明确说明了它的用途：_{`Common/Orders/OrdersResponseWrapper.cs:31`} 两个方法都以 `MakeRequestOrThrow<OrdersResponseWrapper>(request, …).Orders` 结束，将包装器丢弃在地板上。在整个仓库中搜索 `grep -rn "OrdersResponseWrapper" --include=*.cs` 返回了三个结果：类声明和这两个 `return` 语句。**`Length` 被反序列化，但从未被任何东西读取。** 一个调用者的后果是，没有办法回答“总共有多少订单？”或“我完成了吗？”除了请求页面直到收到一个短页面。你无法调整进度条，无法预先分配，也无法事先决定是否这是一个 3 页的工作还是 250 页的工作 — 这正是决定是否应该使用此 API 的决定。<br> <br> 相关的见解已经做出了正确的选择，并返回了具有完整 `Length` 的 `InsightResponse`（`Api/Api.cs:537`、`823`），以及具有 `LiveLog.Length` 的 `ReadLiveLogs`（`Api/Api.cs:759`）。订单是独一无二的。<br> <br> **问题：** 返回包装器（或者一个执行此操作的重载），以便 `Length` 到达调用者。如果 `List<ApiOrderResponse>` 返回类型需要保持兼容性，那么一个重载或一个 `out int total` 都是可以的 — 重点是，数字已经通过了网络，不应被丢弃。<br> <br> (b) 没有分页辅助函数 — 每个调用者都手动循环<br> 今天要读取 N 个订单，您已经知道三个未在 Python 中文档说明的事情：`start`/`end` 是索引，`end - start` 必须 ≤ 100，并且您通过一个短页面来检测结束（参见（a））。因此，每个调用者都编写了相同的 `while` 循环，并且在最初几次尝试中都会略微错误。<br> <br> 研究人员的第一反应是存在一个流式辅助函数 — 字面上第一次尝试是在