4.1 client reconnect bug

["J. Bruce Fields" <bfields@fieldses.org>]

Following up on a pub conversation from a couple weeks ago:

The client apparently assumes that (in the absence of state protection)
sending a SEQUENCE over a new tcp connection to the server automatically
associates the new tcp connection with both the forechannel and
backchannel of the session.

The server currently assumes that the new tcp connection should be
associated only with the forechannel.

RFC 5661 sides with the forechannel-only convention:

	- 2.6.10.6.2: "If the client wants to use additional connections
	  for the backchannel, then it needs to call
	  BIND_CONN_TO_SESSION on each connection it wants to use with
	  the session."

	- 2.10.13.1.2: "If the connection that was lost was the last one
	  associated with the backchannel, and the client wants to
	  retain the backchannel and/or prevent revocation of recallable
	  state, the client needs to reconnect, and if it does, it MUST
	  associate the connection to the session and backchannel via
	  BIND_CONN_TO_SESSION."

	- 18.34.3: "If, when the client ID was created, the client opted
	  for SP4_NONE state protection, the client is not required to
	  use BIND_CONN_TO_SESSION to associate the connection with the
	  session, unless the client wishes to associate the connection
	  with the backchannel."

That means that currently if the client attempts to reconnect (e.g. to
resend a timed-out rpc), it will see SEQ4_STATUS_CB_PATH_DOWN_SESSION
set on future SEQUENCE replies.

--b.