Ipv4L3Protocol tracing enhancements, for FlowMonitor

[Mathieu Lacage]

The idea of adding more trace sources to the existing models is a great idea but
if there are really a lot of them, we should try to give them some consistency
with regard to the format of the packets they receive. 

i.e., I see that some trace callbacks get packets with ip headers, others don't
and I fail to see any kind of logic about when the header is to be expected and
when it is not expected.

http://codereview.appspot.com/110125/diff/1/2
File src/internet-stack/ipv4-l3-protocol.cc (right):

http://codereview.appspot.com/110125/diff/1/2#newcode393
Line 393: Ipv4Header ipHeader;
this is oh so weird: m_dropTrace gets different packet content from m_rxTrace on
line 387 above.

http://codereview.appspot.com/110125/diff/1/2#newcode410
Line 410: m_dropTrace (ipHeader, packet, DROP_BAD_CHECKSUM, interface);
hrm, interesting, this dropTrace was getting a packet without ip header in it.
Inconsistent line 387

http://codereview.appspot.com/110125/diff/1/2#newcode492
Line 492: m_txTrace (packetCopy, ifaceIndex);
and, now, m_txTrace is called _with_ the ip header in ? What is the difference
between m_txTrace and m_sendOutgoingTrace ?

[gjcarneiro]

For the 3 new trace sources I introduced, as well as modifications to the Drop
trace source, I have consistently chosen to offer the packet without IP header
plus the IP header separately as a parameter.  I have not made any attempt at
consistency with Tx/Rx trace sources.

One could argue whether it is better to offer packets with or without IP header
already serialized.  However, in my FlowMonitor use case it quickly became clear
that I would always be needing the IP header, and for that reason it is simpler
and more efficient to receive the IP header separately.  In fact, the flow
monitor only needs to query some IP header fields, plus the GetSize method of
Packet.  Adding a Deserialize method call to this would likely increase the
monitoring overhead.

The difference between Tx/Rx and SendOutgoing/LocalDeliver/UnicastForward is
that the latter ones are higher level.  For each SendOutgoing, you are going to
see one Tx.  For each LocalDeliver you will have a matching Rx.  For each
UnicastForward you'll see one Rx followed by one Tx.  So, you see, by looking
only at Rx it is not clear whether this is a local delivery operation or a
forwarding one.  Likewise, if you see a Tx it can either be the result of a
locally generated packet or a packet simply being forwarded in a router.