[reSIProcate] memory management and asynchronous activity in TransactionState.cxx

[Daniel Pocock <daniel@xxxxxxxxxxxxx>]

I've been looking over TransactionState.cxx with the intention of adding
more asynchronous possibilities, for example, allowing MessageDecorator
to do some async jobs

A few things stand out:

- One problem area is memory management, making sure that the SipMessage
is not inadvertently deleted too soon (while async in progress) and not
left hanging around either.  I notice that the SipMessage
(mNextTransmission) is just a regular pointer - is there any reason not
to use SharedPtr or auto_ptr for this?

- the last async activity that takes place before decoration is the DNS
activity (mDnsResult) so I thought that might provide a useful model for
other async activities.  Should this be further generalised, e.g.
instead of having a bool mWaitingForDnsResult, keeping some enum that
represents the state?  Or is it better to keep extra flags, e.g. bool
mWaitingForDecorator?

- are there any other asynchronous activities that anybody can envisage
adding to this part of the code in future?

- to avoid disruption to existing MessageDecorator users, I'm likely to
add some virtual method with a default implementation that calls the
existing synchronous decorateMessage(), e.g.

      virtual bool decorateMessage(SipMessage &msg,
                                  const Tuple &source,
                                  const Tuple &destination,
                                  const Data& sigcompId,
                                  Fifo<TransactionMessage>&
asyncHandlerFifo)
      {
         decorateMessage(msg, source, destination, sigcompId);
         return true;
      }

and anybody who wants to do something more lengthy can override that
method, start a thread, return false and post the result back on the
fifo when ready.  Does this seem like a reasonable way to avoid API
disruption?