Flows are preallocated at startup and stored in protocol specific caches.
FlowKey is used for quick look up in the cache hash table.

Each flow may have associated inspectors:

* clouseau is the Wizard bound to the flow to help determine the
  appropriate service inspector

* gadget is the service inspector

* data is a passive service inspector such as a client config.

FlowData is used by various inspectors to store specific data on the flow
for later use.  Any inspector may store data on the flow, not just clouseau
gadget.

FlowData reference counts the associated inspector so that the inspector
can be freed (via garbage collection) after a reload.

There are many flags that may be set on a flow to indicate session tracking
state, disposition, etc.

==== High Availability

HighAvailability (ha.cc, ha.h) serves to synchronize session state between high
availability partners.  The primary purpose is to exchange session state with the
goal of keeping the session caches in sync.  Other clients may also register
with the HA service to exchange additional session data by implementing one or
more FlowHAClient classes.

HA uses Side Channel Connectors and/or DAQ module IOCTLs to transmit and receive
HA state messages.  A full duplex Side Channel is required for Side Channel
communications.  A DAQ module that supports the IOCTLs for setting and getting
HA state is required for a functional DAQ-backed setup.  Modules that do not
support these IOCTLs will silently fail and present no HA state on future
packets in the flow.  HA state will be queried from the DAQ module prior to new
flow creation when the appropriate DAQ packet message flag has been set on the
initiating packet.

The HA subsystem exchanges two high level message types:
  - DELETE: Indicate to the partner that a session has been removed.  No
additional HA client status will be exchanged.  (Not used for DAQ-backed
storage.)
  - UPDATE: Indicate all other state changes.  The message always includes
the session state and optionally may include state from other HA clients.
By default, the update messages are incremental.  In the case of DAQ-backed
storage, the update messages are always fully formed.

The HA subsystem implements these classes:
  - HighAvailabilityManager - A collection of static elements providing the
    top-most interface to HA capabilities.
  - HAMessage - A wrapper around the actual message and includes a cursor and
    convenience functions for producer/consumer activity.  Passed around
    among all message handing classes/methods.
  - HighAvailability - If HA is enabled, instantiated in each packet thread and
    provides all primary HA functionality for the thread.  Referenced via a
    THREAD_LOCAL object pointer.
  - FlowHAState - One per flow and referenced via a pointer in the Flow object.
    Contains all dynamic state information.  A set of get'ers and set'ers are
    implemented to help manage the flags, client pending flags, and timing
    information.
  - FlowHAClient - All HA coordination is managed via a set of FlowHAClient's.
    Every function that desires to use HA capabilities defines one FlowHAClient
    object within the packet processing thread.  Each client is provided a 
    handle bit-mask as part of the pending logic.  The client may set the
    pending bit to indicate the desire to add content to the HA message.
    A maximum of 17 clients may existing (numbers 1-16, corresponding to the
    16 bits of the pending flags.  Client 0 is the 'session', is always present,
    and is handled as a special case.  Client 0 is the fundamental session HA
    state sync functionality.  Other clients are optional.

