ibssa: Encapsulate global variables in common stucture

To support different SSA daemon types, provide some common
data structures, but allow the caller to indicate the actual
structure size.  The idea is that callers can embed the
common structures inside their own structures.

The data structures form into a hierarchy.  Going from the
top of the hierarchy down, they are:

class - represents the daemon
device - represents an RDMA device
port - represents a port on an RDMA device
service - is associated with a single SSA database

All data structures are extensible, which allows each type
of SSA daemon (core, distribution, consumer) to extend the
types based on their specific needs.  For example, the consumer
(ibacm) can extend the service structure in order to cache
path records.

Signed-off-by: Sean Hefty <sean.hefty@intel.com>
ibssa: Switch from device list to array

Use an array to store device information, rather than
placing them into a list.  Yeah, this is being done on
a whim, but does eliminate some dlist use.

Signed-off-by: Sean Hefty <sean.hefty@intel.com>
ibssa: Update MAD definitions

Copy and rename ibssa_mad.h into infiniband/ssa_mad.h.  The move
is so that the file may be installed.  The rename removes the
redundant 'ib' prefix, since the file is in the infiniband
directory.  We leave the existing file until other components
are migrated to the new definitions.

Now that libibumad includes MAD definitions, use them where
available.  Remove 'ib_' prefix from SSA MAD definitions -
just use 'ssa' instead.  Provide a few other cleanups.

To avoid overloading the term 'service', the updated structures
refer directly to a specific database.

The updates assume that SSA join requests are tracked per port,
similar to multicast joins.  This helps to ensure that there's
only a single copy of any database available through any port.

Signed-off-by: Sean Hefty <sean.hefty@intel.com>
ibssa: Add control and upstream threads

The control thread is responsible for processing asynchronous
events on devices/ports, listening for incoming connection
requests, and MAD handling.

The upstream thread manages the state of a single SSA service,
identified by a database.  It joins an SSA group, handles
retries, connects to the parent, and manages the database.
Currently, the upstream thread simply joins the SSA group.

Communication between the control thread and upstream thread
is done using a socketpair.  MADs are forwarded between the
control thread and upstream thread(s).  Device events are
similarly reported over the socketpair.

Signed-off-by: Sean Hefty <sean.hefty@intel.com>