优化定时抢票计时逻辑，修复定时抢票无法取消的bug

[gpc123456]

优化定时抢票逻辑

• 将数据准备过程前移，到抢票时间直接提交订单准备请求，可以节约一点构建payload的时间
• 优化定时抢票剩余时间WebUI外显方式，当距开票时间>5秒时，每秒刷新一次外显数据；当距开票时间<5秒时，不再刷新外显数据，显示“即将开抢”
• 当距开票时间<5秒时，计算完开票时间差后，切换为使用time.perf_counter()方法进行计时，以获得相较于sleep()方法更加精准的计时

修复定时抢票无法取消的bug

• 将停止标志检测移至倒计时循环中，修复无法停止倒计时的bug
• 同时修复了停止定时抢票状态无法外显到WebUI中的bug

[mikumifa]

感谢pr

[mikumifa]

不过我不太提前确定会不会导致token是错的

因为没有测试过开票时间前准备会不会出错

你有测试过吗

[gpc123456]

这个数据准备应该是直接读取的配置文件json的数据，只要不在开票前发请求应该没有问题

我测试了开票后联票的抢票，没有发现异常，目前还没找到还没有开票的票务去试，不过理论上应该也没有问题

如果不放心的话，也可以将数据准备再放回原来的位置，这个过程也挺快的，对请求发出时间影响不太显著，看log将数据准备前置大概也就能快个5ms左右的样子

[mikumifa]

以前有人实践过出问题了

[mikumifa]

当然你这个不一定有问题，不过不测试的话可能会被回滚。。。

[gpc123456]

以前有出问题的话，保险起见还是先回滚吧，避免到时候抢票的时候出错

不过前面等待开票那段代码应该是没有问题的，我用了bw和bml已开票的场次做实验，把开始时间设的往后一点，都可以正常进入抢票过程

[mikumifa]

ok