feat: extract alias from msg

[jiz4oh]

微信本身存在已知 bug 会导致群昵称无法正常获取，在小红书上有很多相关反馈。该 pr 使用新的思路从三个来源获取群昵称：

1. 撤回消息
2. 回复消息
3. at 消息

微信会在上述三种消息中添加目标的群昵称，经测试 撤回消息 和 回复消息 均能稳定获取，但 at 消息中存在多种边缘情况，为降低错误率，仅正则匹配 @ 开头且 @ 单人的消息体。

并使用 sqlite 持久化保存群昵称

[0honus0]

微信本身数据库没这些东西吗？
sqlite 是不是有点重了

[jiz4oh]

微信本身数据库没这些东西吗？

本身是有，原来有一个 GetGroupListBySql 可以提取微信数据库的数据，但是实测下来这个数据是不全的，很多群的数据都没办法获取。我原以为是 comwechat 的 bug，后来用 vnc 连接上去发现在微信页面上也没办法看到对应的昵称，在小红书上搜到了很多人的反馈，判断是微信本身的问题

sqlite 是不是有点重了

一开始是实现了一个 pickle 的版本，后面改为 sqlite。两个实现对于该需求都是可以的，或者也可以使用 json

1. 改为 sqlite 的主要考虑是在最近的更新里面觉得 efb-comwechat-slave 有一定必要引入自己的持久化方案，比如

   efb-wechat-comwechat-slave/efb_wechat_comwechat_slave/ComWechat.py

   Lines 803 to 818 in 19be7fb

   	comwechat_info = msg.target.vendor_specific.get("comwechat_info", {})
   	if comwechat_info.get("type", None) == "animatedsticker":
   	refer_type = 47
   	elif msg.target.type == MsgType.Image:
   	refer_type = 3
   	elif msg.target.type == MsgType.Voice:
   	refer_type = 34
   	elif msg.target.type == MsgType.Video:
   	refer_type = 43
   	elif msg.target.type == MsgType.Sticker:
   	refer_type = 47
   	elif msg.target.type == MsgType.Location:
   	refer_type = 48
   	elif msg.target.type == MsgType.File:
   	refer_type = 49
   	elif comwechat_info.get("type", None) == "share":

   要求获取 msg.target.vendor_specific 中的 wechat xml 数据，之前的实现是存储于 master channel 中，但 etm 官方实现是不支持持久化 vendor_specific，必须使用我的 fork 才行。引入 sqlite 之后就可以改为从 efb-comwechat-slave 的数据库中提取数据，不依赖于 master channel 的实现
2. 引入 sqlite 后可以将每条微信的消息持久化下来以实现 efb 框架规定的 get_message_by_id
3. sqlite 可以实现行数据更新，pickle 和 json 都是序列化全量数据

[0honus0]

也可以 不过感觉增加存储的话要有对应的清除策略 要不会随着使用时间越变越大

[jiz4oh]

目前 etm 的 tgdata.db 和微信本身的数据库也是会持续增长的，所以在磁盘占用上我觉得用户本身是可以接受的。对于当前需求来说，群昵称数据膨胀到一定极限就不会再膨胀了（理论上当所有的群成员的昵称都被记录过之后）