Allow retrieval of VLAN tag from packet-in match. The VLAN tag might be here if the switch popped the VLAN tag from the packet itself prior to encapsulating it in the packet-in message.

Add new detailed-match property to define source and destination addresses to match on in each layer. Also add in-port as an optional match for the existing match property.

Change log levels of frequent, unnecessary logs to debug. Were previously warn. Add new RoutingManager to properties

Changed ArrayList<> types to ImmutableList<> where applicable. OpenFlow messages are now cached in Forwarding.deleteFlowsByDescriptor().

* Eliminated (new) warnings
* Fixed indentation
* Removed excess blank lines
* Improved some varable names
* Removed (unneeded) commented-out code
* Fixed up comments
* Added @Override annotations

ForwardingTest.testForwardDeleteFlowsByDescriptorMultiple() passed in Eclipse, but failed when run by "ant test".
Changed Forwarding.deleteFlowsByDescriptor() to use List<> instead of Set<> to simplify the unit test.
Tests now pass in every configuration I'm able to run them (eclipse single test, eclipse test class, eclipse all tests, ant all tests).

Also general code and comment cleanup.

This deletes/add flows from the switch out of forwarding when the firewall rule changes.

Added test cases for Forwarding if there is a decision packet.

Updated Firewall.java so that addRule and deleteRule and enableFirewall announce that a rule is being changed in the firewall. Then the IRoutingDecisionChangedListener shall alert Forwarding to update the flowtable accordingly.  None of this is tested and the TopologyManager needs to be fixed.  I might even want to move the change out of TopologyManager altogether since RoutingDecisionChange doesn't concern it.

Update Forwarding to support specifying a default table ID for flow insertion. It's flow table 0 by default, but it can be overridden using the net.floodlightcontroller.forwarding.Forwarding.table-id=X config parameter in floodlightdefault.properties. Set X to any table b/t 0 and the max.

Getting there w/OF1.5 support. Just need a switch that supports it (well) to do some more thorough testing.

TODO:
   * RoutingDecisionsChanged event
      * Define Listener class
      * Add Listener registration/messaging (probably going into IRoutingService)
      * Add code to fire event when firewall rules change.
      * Add code to fire event when firewall enable/disable happens.
      * Add code to handle RoutingDecisionsChanged in Forwarding
   * Unit tests
   * Functional tests

Handle link and port down events in Forwarding. Remove flows ingress and egress a failed port or link to eliminate stale entries. This is done in Forwarding instead of the Link Discovery Manager, since some user modules might not want their flows removed and wish for them to persist until the link comes back up.

Fired when receive a ROLE_STATUS message, at Master to Slave transitions, switch become deactivated.

Modified Forwarding and ForwardingBase to use setInstructions instead of setActions in OF 1.1 or later. New openflowj-2.0.0-SNAPSHOT.jar that duplicates the shortcut used for FlowMod setActions in version 1.3 to versions 1.1, 1.2 and 1.4

Patch Forwarding's pushPacket and pushRoute. We do not want to push a packet if the command is delete or delete-strict.

Added ability to disable ARP flows in Forwarding. Many hardware switches cannot handle ARP flows. ARP flows on by default; turn off/on via 'flood-arp' in floodlightdefault.properties. Also, finished integrating new topology service/routing into Forwarding. This required a few more null checks to handle cases where packet-ins are received while the controller is starting/still discovering the topology/links.

Integrated new topology code and updated unit tests to a passing state. I'd be more comfortable adding more unit tests to the topology. Also made some changes to the link discovery manager's latency subsystem. We start with a baseline latency based on the switch's features reply turnaround time. This should be relatively quick -- just like an echo. Next step for latency is to keep a rolling list of past latencies for more defined topology updates based on latency updates. We don't want to update latencies too frequently, since tiny changes (or outliers) shouldn't require a complete topology recomputation.