DynamicPartitionChannel thrift协议使用backup request产生coredump

**Describe the bug (描述bug)**
使用DynamicPartitionChannel thrift协议访问下游时偶发coredump，下游分库数量>=1都会出现该问题，coredump位置在selective_channel.cpp:375，
定位发现thrift_message的包装未实现反射
GetReflection拿到空指针调用Swap产生了core。
main_cntl->_response->GetReflection()->Swap(main_cntl->_response, _cntl._response) 语义看起来是要Swap两个res，于是尝试强转手动调用了ThriftMessage的Swap方法:
auto thrift_res = static_cast(main_cntl->_response);
thrift_res->Swap(static_cast(_cntl._response));
修改完毕之后压测会继续偶发core在 thrift_message.h:192行，似乎response有点问题。
尝试定位修改了一些代码，可能跟backup request cancel行为有关。

**To Reproduce (复现方法)**
DynamicPartitionChannel thrift协议访问下游开启backup request，max_retry=1，timeout=800ms，backup定时器可以调小来增加触发概率。

**Expected behavior (期望行为)**
1.期望解释一下main_cntl->_response->GetReflection()->Swap(main_cntl->_response, _cntl._response)场景含义，看了channel一些代码，感觉写的有点绕。
2.修正DynamicPartitionChannel backup request行为。

**Versions (各种版本)**
OS: centos6
Compiler: gcc492
brpc: tag:1.2.0
protobuf: 3.8

**Additional context/screenshots (更多上下文/截图)**

Reproduce the coredump with DynamicPartitionChannel, thrift, backup requests, max_retry=1, timeout=800ms, and a shortened backup timer. Inspect selective_channel.cpp:375 and thrift_message.h:192, then trace the GetReflection/Swap path and backup-request cancellation behavior. Done means the configured reproduction no longer crashes and the response handling is corrected.

Written by the indexing model from the issue text.