hammer2 - Retool dmsg mechanics to improve virtual circuit design 1/2
* Rip-out the circuit structures and forging code. These changes simplify
the DMSG code considerably.
* Retool the core command/response messaging mechanics to allow either
side of a transaction to initiate commands and receive responses.
This means we cannot use DMSGF_REPLY to determine whether the transmit-side
or receive-side state RBTREE holds the msgid. Instead we add two more
flags DMSGF_REVTRANS and DMSGF_REVCIRC to tell the receiver which RBTREE
holds the msgid and/or circuit id.
* Retool to allow transaction stacking. Sub-transactions can now run under
their parents.
* Retool the transaction code to provide virtual circuit functionality
through the use of transaction stacking.
With these changes, the normal SPAN mechanism which operates using
open transactions can also be used to route messages over the SPAN.
There is no longer a need to forge a return path because sub-transaction
commands can now be initiated 'out' over an active, received SPAN
transaction.
This part is not completely working yet, it needs the actual routing
code and some adjustments to the SPAN mechanism to prevent path ripups
from interfering with any in-progress transactions. Ultimately the
availability of a new path would have two be detected by the end points
so new 'connections' can be forged over the new, better path.