[refactoring] Multi-tenancy/多租户支持 #1
Description
开源后的重构计划
由于maid需要使用Twitter的API，而使用API的KEY申请不易，部署一个新实例变得十分困难；自用还好说，让其他人使用的门槛有点过高了。
那么要解决这个矛盾，改进的方案如下：
- 先前抛弃的RssHub模块对多个目标监听已经有实现，如果选择自建的话能避免官方实例缓存时间过长的问题，但其他部分依旧需要大改。
- 不过既然maid已经实现了对Twitter的接入，因此我有了个大胆的想法：多bot支持、服务化。
以下是我的设计草稿
maid - 监听器
从数据库获取需要监听那些推主，推尽管往数据库塞，有更新仅需推送给app一次。
新接口：触发更新监听列表
监听列表实现(?)bot专用推特号，关注所有需要监听的推主，然后监听自己时间线
koishi-app - Bot
从数据库获取配置，动态注册koishi配置(?)，被动重启以加载租户变更(?)
单独watcher实例，监听maid的更新推送，然后找到对应koishi实例触发推送
如果koishi-app也多实例，需要平衡多个实例直接的配置数量（使用本地coolq和自带coolq的分开？），maid也要推送到所有实例
监视运行状态略麻烦，每个koishi实例定时向数据库/文件汇报，根据最后更新时间判断在线，在线获取日志？
frige - 数据库
加一张任务表，将部分字段从推文表移至任务表；
| 字段 | 类型 | 注释 |
|---|---|---|
| tid | int | 外键推文表 |
| tenancyId | int | 租户Id |
| taskId | int | 命令引用的Id，取代旧推文表的自增id |
| hide | bool | 【迁移】是否隐藏 |
| published | bool | 【迁移】是否已发布 |
taskId & tid & tenancyId 唯一，为了避免用户使用的id不连续，taskId在条件内自增
有推文入库（推文表）时，按租户订阅，插入到任务表；取队列时也从任务表取（而不是原来直接从推文表取）
oven - 烤图机
新前端接口(Web interface)
后端重构弃用wkhtml2image，使用headless Chrome/Firefox;
单独chrome进程实例，多图同时烤时用同一个chrome，队列限制同时烤图数，chrome闲置一段时间退出(?)
新模块 Web console
管理租户
用户管理，注册登陆、会员充值(?)
租户管理，新建消除、修改配置
可能用得上的配置：监听推主(*列表)、监听发布渠道(*列表，如B动态/微博等)、cqhttp地址(*本地实例)、工作群号(*列表)、推送群号(*列表，通常同工作群)、*是否允许私聊/好友上班、*附加插件参数
(带*的可以设计为高级用户特性)
在线任务表管理
针对租户，在线koishi-app功能实现，主要方便批量删藏任务
接入方法
在web上注册用户，新建一个租户后，按配置自带coolq+cqhttp带外网，用ws/HTTP正向接入
或使用我们提供的coolq实例(?)