Changes to Close Handling for R1.2
----------------------------------

In the R1.2 change handling has been altered to support immediate
session down notifications regardless of whether there are pending
IO's present. In addition, the semantics for open-side and accept-side
sessions have been made similer.

In rmc releases prior to R1.2 sessions can be torn-down 2 ways: through
explicit action via rmc_close, or through application failure via pm
notifications. Unfortuantely, the semantics differ for the two methods.

Explict closes are supported for open-side sessions. When the rmc_close
operation is performed on and open session, a message is sent to the
accepting-side session and the session structure "closed" (i.e: removed
from RMC structures). Once the rmc_close call has completed, the memory
used for the session can be reused or freed. On receipt of the close msg
on the accept-side, the accept-session corresponding to the open-side 
session is "closed", and then the close_callback registered via the 
rmc_listen call is fired, indcating whether the session structure can be
freed or not (i.e: when no_free is indicated, RMC resuses the session
structure).

Explicit closes are supported on accept-side sessions. When rmc_close is performed, -NO- message is sent to the corresponding open-side sessions. Rather, the
accept-side session is "closed" - the close_callback handler is fired similar
to when a open-side close message is received. The open-side will not discover
the explicit accept-side close until a pending operation times out.

PM notifications work differently. When the open-side application crashes, PM will send out a session abort msg to the accept-side application. On reciept of 
this notification, the accept-side session is "aborted". Note that "aborted"
means the session is marked as down, but RMC still maintains the session. 
Unfortunately, this differs from "closed" connection, requiring and explicit
accept-side rmc_close operation. If there are pending IO's, the "abort"
operations marks the IO's as failed and the accept-side applications discovers
the abort via the normal RMC_MSG_CHKSTATUS mechanism. If no pending IO's
exist, the accept-side session will keep the "aborted" session around for
a potentially long period of time (until session recycling is kicked in).
Similar is true when accept-side applications crash - the open-side app gets
a PM abort msg, but the session hangs around until a pending IO fails (which
tends to occur more often because open-side apps control the IO model (servers
tend to passively wait).

For the R1.2 release, explicit closes and PM abort detections work similarly.
Small difference still exist betwen open-side and accept-side handling mostly 
for application compatability reason and are described below.

Explicit closes now generate close messages in both directions: that is, rmc_close on accept-side sessions generate close messages similar to rmc_close on 
open-side sessions. 

For explicit closes on open-side sessions, things work as expected: 
the close message goes out, the session is "closed" and the
session memory free to be resued or freed. The accept-side session that
receives the close msg functions has changed subtly: if a callback is 
registered in rmc_listen, the accept-side session is closed and the close 
callback is fired in a fashion compatible with pre-R1.2 releases. Prior
to the callback however, the received close msg is passed to the application 
so that it can be retrieved from the session complete queue with rmc_waitfor_msgor rmc_get_completed_msg.  The close msg is always returned with 
the RMC_MSG_CHKSTATUS indication and always on the listen session (similar
to any pending IOs aborted in the process). Application must explicitly 
handle this new message (typically freeing the space consumed).


When explicit closes are performed on accept-side sessions, close messages
are always generated to the corresponding open-side session. 
Things change a bit when rmc_close is issued on accept-side sessions: the
close message is sent to the open-side, the session is "closed", and the 
close_callback is fired with a free indication - again, similar to prior
releases.....however, app semantics for the open-side session receiving the 
close msg is new and must be handled.