It used to mean bytes per second.  Now it means bits per second.  To
avoid worrying about client-side versions and updating, we'll keep the
client unmodified and convert statistics on their way through the server.
Who doesn't like ugly hacks?

Aggressively flush tables, and mysqlcheck on boot.

We can't add all the interfaces all the time (since we have thousands
of them, and we're frequently repopulating the monitoring database), and
we can't statically determine the set we care about, either (since it
depends which VLANs we report as externally visible).

 - Do not report interface addresses unless we have a valid dotted decimal
   IPv4 address
 - Always give interface roles as either "control" or "experimental"

After today's discussion on the ops-monitoring teleconference, where
the understanding was that this is the proper interpretation.  (When
two sites describe the same interface, the two URNs must match exactly;
in contrast, whatever URLs are advertised "belong" to the site
describing it.)

(Again.)

The pieces are:

 * A monitoring daemon (clientside/protogeni/shared-node-monitor), which
   runs in each Xen shared node dom0, and gathers node and interface
   statistics.  It communicates these over the event system with...

 * A listening daemon (event/monitoring/shared-node-listener), running
   on the local boss node, and inserts everything it hears into the
   MySQL database "monitoring".  This database is also used by...

 * A site-wide monitoring daemon (protogeni/scripts/mondbd), periodically
   polling the normal testbed database (nodes and interfaces tables) and
   copying snapshots of the important pieces into the monitoring database.

 * The monitoring database is also read by a WWW front end invoked as a
   WSGI process by Apache.  This front end is developed by the GPO and
   modified to work with ProtoGENI, and is maintained in an independent
   repository.