工单状态新增 IN_PROGRESS 移除 FULFILLED

[leeyeh]

要解决的问题

1. 目前有两个表示「结束」的状态，FULFILLED 与 CLOSED。在设计上他们分别代表「问题解决了」与「问题不一定解决但因为各种原因不再需要跟进了」。但在实践中不管是对用户还是对客服，这两个状态都几乎没有差别，没有明确的用户或客服需要区分他们的场景。
2. replySoon 操作会让工单进入「等待客服稍后回复」的状态，这个状态与「等待客服（立即）回复」对用户对客服都是有实质区别的。对客服来说，这部分状态的工单需要的处理不是立即回复，而是过一段时间（比如每天固定时间回顾或者异步的由其他事件触发）再回复，因此需要能通过筛选区分这两种状态。对用户来说，这个状态会建立「需要一段时间处理」的预期。

方案

1. 将 FULFILLED 合并进 CLOSED 状态
2. 增加 IN_PROGRESS 状态

新的状态转移如下图：

ENUM	值	描述	客服视角	用户视角
NEW	50	新工单，还没有客服回复	🔴	⚪
WAITING_CUSTOMER_SERVICE	120	等待客服回复	🔴	⚪
IN_PROGRESS	130	处理中，客服会在稍后回复	🟠	⚪
WAITING_CUSTOMER	160	等待用户回复	⚪	🔴
TO_BE_CONFIRMED	220	待用户确认解决 （客服点击「认为已解决」时会转移到该状态）	⬜	🔴
CLOSED	280	已关闭	⬜	⬜

图例：

• 🔴（进行中）需要响应
• 🟠（进行中）需要回访
• ⚪️（进行中）无需关注
• ⬜（已结束）无需关注

向前兼容

因为状态是作为公开 API 的一部分暴露的需要谨慎考虑向前兼容性。
在这个改动中，操作（action）没有变化，只有状态有增减，所以只会对工单状态相关的部分会有影响。
移除 FULFILLED 状态（用 CLOSED 状态替代）不会有向前兼容的问题（除了需要提前手动迁移一下视图与自动化里的配置但这部分是我们一起控制的不会有客户端用到）。但增加新的 IN_PROGRESS 则可能会导致旧客户端在展示时遇到问题，因此这个改动会让 API version 跳到 v3。因为 v3 API 并没有大的变化，所以代码仍然与 v2 用一套，只在部分路由中根据版本特殊处理。更具体一点，需要在 v1 v2 中将新的 IN_PROGRESS 状态返回为 WAITING_CUSTOMER_SERVICE 状态（再早的直接调用底层存储 REST API 的用法就没办法向前兼容了）。

一些思考记录

其实 NEW 与 WAITING_CUSTOMER_SERVICE 也几乎没有区别，但这次不准备动 NEW 状态。一是目前区分这两者并没有带来很多麻烦，二是对客服来说有时候会关心组里还没有人回复过的工单（NEW）但不太关心组里已有其他人负责但等待客服回复的工单。