建议将翻译与排版解耦

[jgewbem]

功能描述

一些 API 支持高并发的翻译请求，但是目前该项目似乎还是按页串行处理的

因为设置的线程数往往大于当前页面文字块数，所以实际工作达不到设置的线程数，极端点退化成单线程处理。遇到生成较慢的服务可能耗时会很久

一种可能的解决方案是加一步翻译缓存所有文字的步骤：

翻译： 1. 解析所有页面的文字 2. 多线程处理翻译 3. 写入本地缓存

排版（现有的代码保持不变）： 1. 解析单页文字 2. 读取缓存的翻译 3. 排版当前页面

这样既可以更”并行“地翻译，又不会大幅影响项目的现有逻辑

[awwaawwa]

其实也不用二阶段翻译，毕竟PDF各页之间天然独立，只需要把处理某一页的代码写成async def handle函数，然后直接发起所有task（或者想省mem的话找个信号量限制一下），并用async.gather并行运行。handle里可以顺序执行，也可以把部分性能瓶颈代码改成并行执行，比如说获取到当页所有文本后并行翻译。

tasks = []
for page in pdf_pages:
    task = handle(page)
    tasks.append(task)

results = await asyncio.gather(*tasks)

当然，还可以用TaskGroup实现自动等待所有task运行完成。

这么写以后不太好调试，所以再搓一个一次处理一页的方便调试。

for page in pdf_pages:
    await handle(page)

然后出于省钱&加速调试等目的，再用sqlite+peewee搓一个翻译缓存，把现在这个换掉，就差不多了。

#167 (comment) 里提到在等有缘人改async。

根据我上述分析，其实要改的也不少，所以顺手把取消支持也搞了，最后再把现有sync代码也写点胶水代码粘到async上，并提供取消支持（比如说sync代码只处理某一句的翻译，批量的for放到async代码里）。

ps，最近没时间，有空了（大概月底吧）再去改，最终方案不一定是以上方案。

pps，各种翻译的限速用个信号量就解决了。