客户端 quic_stream_shutdown 有概率会调用失效

[stopandjoin]

Android平台上，在客户端调用quic_stream_shutdown时，有小概率会出现，客户端没有stream closed回调的情况。
目标stream 是客户端创建的双向stream，在客户端通过以下接口关闭流：
int ret_w = quic_stream_shutdown(mConn,streamId,QUIC_SHUTDOWN_WRITE,0);
int ret_r = quic_stream_shutdown(mConn,streamId,QUIC_SHUTDOWN_READ,0);
以上两个调用的返回值都是正常的， 且server端也能收到 stream closed 回调。 但是客户端会有一定的概率，一直没有stream closed回调。 麻烦帮忙看看。

[iyangsj]

@stopandjoin 执行这两个quic_stream_shutdown后，会触发双方发送 RESET_STREAM 帧强制关闭流，在交互完成后才会最终执行om_stream_closed回调并关闭流。

把相关的 client/server 的debug 或 trace 级别日志发出来看看

[stopandjoin]

server.log
client.log

如上log，client端发送 RESET_STREAM 的时间点为：08-12 18:00:50.822

[stopandjoin]

@iyangsj 如以上log所示，会有 received RESET_STREAM frame before recv completed with error code 0 这种打印，不知是否有影响。
我们本来是打算重复使用一个id的，发现一个id使用后，就算shutdown了也没法重用。 所以这个log 对应的场景是，shutdown目标stream后，new新的stream，id会按规律累加。

[sharewzy]

目前发现以下问题点：
client端在做shutdown动作时，在发送ss和rs时会携带一个其它stream的数据端，导致server端解析时会按照ss->rs->data的数据解析，解析完data后会直接发送ak，此ak不会带rs，然后客户端会先收到ac，再收到rs，解析的逻辑就不太对了。
正常ok的流程是：shutdown的时候，客户端发送ss+rs，不会带data，服务端解析之后回复ak，带rs，客户端正常流程再解析，触发close。

[iyangsj]

下个版本会解决，预计8.20发布