msg/async: do not trigger RESETSESSION from connect fault during connection phase
Previously, if we got a connection fault during the connect/connect_reply
phase, we would increment connect_seq on the client side and trigger a
RESETSESSION on the server side (because there was not yet an existing
connection to replace). This led to dropped messages, usually in the
form of stuck peering in the rados/thrash suite.
The problem is that the condition for 'reconnect' vs 'backoff' inherited
the test from SimpleMessenger, which had only a STATE_CONNECTING. In
contract, AsyncMessenger also as CONNECTING_WAIT_BANNER_AND_IDENTIFY and
CONNECTING_SEND_CONNECT_MSG, and if we were in these states, we would
increment connect_seq instead of backing off and retrying (without an
increment).
Fix by adjusting the condition to match the range of CONNECTING states
in asyncmessenger.
Fixes: http://tracker.ceph.com/issues/36612 Signed-off-by: Sage Weil <sage@redhat.com>