end node shaping, this change does not affect bridge shaping).

First off, duplex links are not affected. I expect that duplex links are
the majority usage anyway. What I did change is the way we insert the
virt_lans table entries to be exactly like what the NS file does. This will
not affect the delays, but it makes linktest happier (see below) when
testing duplex links.

For lans (more then two nodes) we were always broken. Consider what we have
now: 

 <link client_id="mylan">
   <interface_ref client_id="node1"/>
   <interface_ref client_id="node2"/>
   <interface_ref client_id="node3"/>
   <property source_id="node1" dest_id="node2"
           capacity="50000" latency="15"/>
   <property source_id="node1" dest_id="node3"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="node1"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="node1"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="node3"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="node2"
           capacity="50000" latency="15"/>
</link>

This cannot actually be supported by the virtual topology in the database.

In Emulab the virt_lans table allows you to specify for each node, the
bw/latency/loss going "from the lan to the node" and rbw/rlatency/rloss
"going from the node to the lan". Think of the "lan" as a fake node in the
center of a star.

                        N1
		   bw   |  | rbw
		delay   |  | rdelay
		 loss   |  | rloss
			|  |
           N2  ------- LAN ------- N3
               -------     -------

So one of the lines is "from the LAN node to N1" and the other line is
"from N1 to the LAN node". Ditto for N2 and N3.

In other words, you cannot actually specify a different set of parameters
from a node to each of the other nodes, as the pairwise properties above
imply.  A translation of what we actually do is more like this:

   <property source_id="node1" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="mylan" dest_id="node1"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="mylan" dest_id="node2"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="mylan" dest_id="node3"
           capacity="50000" latency="15"/>

Which allows you to set the simplex parameters for each node TO/FROM THE
LAN.  Each node can a bw/latency/loss to the LAN and a different
bw/latency/loss from the LAN. This is supported in the classic NS file
syntax, although this is not what a simple "make-lan" does; there is
currently no syntax to support that in Geni; a NS file make-lan statement
that sets the delay to 15 means that the delay is 7.5 to the LAN and 7.5
from the LAN, so the delay between two nodes is 15. In the NS syntax, once
you start messing with per-node shaping settings, you have to do it like
above. So in the above example, the delay between any two nodes is 30ms.

But the above is a little too confusing, so rather then doing simplex
parameters I implemented duplex parameters:

   <property source_id="node1" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="mylan"
           capacity="50000" latency="15"/>

If someday we think that people need simplex parameters for each node in a
lan, we can add that.

As for linktest ... I added the linktest agent to Geni experiments, and I
set the sync_server default so that linktest can actually run. In another
commit I will push up the change that export linktest from the CM
interface, as well as portal changes to use it.