* The per-experiment event scheduler now runs on ops instead of boss.
  Boss still runs elvind and uses events internally, but the user part
  of the event system has moved.

* Part of the guts of eventsys_control moved to new script, eventsys.proxy,
  which runs on ops and fires off the event scheduler. The only tricky part
  of this is that the scheduler runs as the user, but killing it has to be
  done as root since a different person might swap out the experiment. So,
  the proxy is a perl wrapper invoked from a root ssh from boss, which
  forks, writes the pid file into /var/run/emulab/evsched/$pid_$eid.pid,
  then flips to the user and execs the event scheduler (which is careful
  not to fork). Obviously, if the kill is done as root, the pid file has to
  be stored someplace the user is not allowed to write.

* The event scheduler has been rewritten to use Tim's C++ interface to the
  sshxmlrpc server on boss. Actually, I reorg'ed the scheduler so that it
  can ...

federation, which is not supported in the version we have source to.
Basically, we run an elvind on each node. The proxy on each node
subscribes to all events for that node from the boss elvind, and hands
them to the local elvind, Each client on the node subscribes to the
local elvind, and gets its events via the proxy. This should reduce
the number of connections to boss, and makes it possible to run agents
inside each virtual node without an FD explosion on boss.

hainv the sender usurp the host field in the tuple. The event library
sets this for the user.

tevd: Proper daemonization code, controlled by debug option.

for verbosity. Add some actual functionality; take TBCONTROL events
and set the eventstate field of the nodes table.

scheme that we discussed in email. Notifications and subscriptions now
take an "address_tuple" argument (I know, crappy name) that is a
structure that looks like this:

	char		*site;		/* Which Emulab site. God only */
	char		*expt;		/* Project and experiment IDs */
	char		*group;		/* User defined group of nodes */
	char		*host;		/* A specific host */
	char		*objtype;	/* LINK, TRAFGEN, etc ... */
        char		*objname;	/* link0, cbr0, cbr1, etc ... */
        char		*eventtype;	/* START, STOP, UP, DOWN, etc ... */

These can be a specific value, ADDRESSTUPLE_ANY if you are a
subscriber, or ADDRESSTUPLE_ALL if you are a producer. The reason for
the distinction is that you can optimize the match expression with the
extra bit of information, and the above structure can make for a
fairly lengthy match expression, which takes more time of course.
You should use address_tuple_alloc() and address_tuple_free() rather
than allocating them yourself. Note that host above is actually the
ipaddr of control interface. This turns out to be more convenient
since free nodes do not have virtual names.

Also added a new tbgen directly. This directory includes 3 programs in
the making:

tbmevd: Is the Testbed Master Event Daemon, to be run on boss and will
handle TBCONTROL events (reboot, reload, etc). It is just a shell of a
program right now, that takes the events but does not do anything
useful with them. Have not defined what the events are, and what DB
state will be modified.

tbmevc: Is the Testbed Master Event Client (akin to tmcc). It
generates TBCONTROL events which the tbmevd will pick up and do
something useful with. This program is intended to be wrapped by a
perl script that will ask the tmcd for the name of the boss (running
the event daemon).

sample-client: This is a little client to demonstrate how to connect
to the event system and use the address tuple to subscribe to events,
and then how to get information out of notifications.

Note that I have not created a proper build environment yet, so new
programs should probably go in the event dir for now, and link using
the same approach as in tbgen/GNUmakefile.in.