MRP-2038 test: reconnect vs bl ast vs resend race.

Reconnecting a client should set a AT flags correctly to avoid -71.
(EPROTO) in logs.
Reconnecting should not abort any RPC in flight but re-send them
instead.

Signed-off-by: Alexey Lyashkov <alexey_lyashkov@xyratex.com>
Change-Id: I041d27f8c46a41fecec0bd32d526140cc374d3e3
Reviewed-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
Tested-by: Alexander Lezhoev <alexander_lezhoev@xyratex.com>
MRP-2038 ptlrpc: client reconnect races

Don't reallocate a new reverse import for each client reconnect.
a reverse import disconnecting on each client reconnect open
several races in request sending (AST mostly) code.

First problem is send_rpc vs class_destroy_import() race. If sending
RPC (or resending) issued after class_destroy_import function was
called, RPC sending will failed due import generation check.

Second problem, Target_handle_connect function stop an update a
connection information for older reverse import. So RPC can't be
delivered from server to the client due wrong connection information
or security flavor changed.

Target_handle_connect function stops update connection information
for older reverse import. So we can't delivers a RPC from server to
the client due wrong connection information or security flavor
changed.

Third problem, connection flags aren't updates atomically for an
import. Target_handle_connect function does link new import before
message headers flags are set. So, RPC will have a wrong flags set
if it would be sent at the same time.

Fourth problem, client reconnecting after network flap have result
none wakeup event send to a RPC in import queues. That situation adds
noticeable timeout in case server don't send request before network
flap.

Signed-off-by: Alexey Lyashkov <alexey_lyashkov@xyratex.com>
Change-Id: Ieeaea52794c9d2a68a6b3cd12e3a7cf3f645d46f
Reviewed-on: http://es-gerrit.xyus.xyratex.com:8080/3525
Tested-by: Jenkins
Reviewed-by: Alexander Boyko <alexander_boyko@xyratex.com>
Tested-by: Alexander Lezhoev <alexander_lezhoev@xyratex.com>
Reviewed-by: Vitaly Fertman <vitaly_fertman@xyratex.com>