Correct race condition in device learning and topology, remove deviceManager from listening linkEvent

This reverts commit 0ae432f4.

Conflicts:

	src/main/java/net/floodlightcontroller/devicemanager/internal/DeviceManagerImpl.java

This reverts commit 51ca40a3.

Conflicts:

	src/main/java/net/floodlightcontroller/devicemanager/internal/DeviceManagerImpl.java

Add 5 seconds for attachment point change from one broadcast domain to another.  When the attachment points flap quickly, the controller should avoid learing the attachment point but should continue processing the packet.

Device manager will have a 5-second time gap to change an attachment point for a host from one broadcast domain to another.

Fix a bug for checking BDDP packet if the packet is not unicast for it to continue down the processing chain.

If the incoming node port is blocked, allow only unicast and BDDP packets to continue down the processing chain.

When the device manager gets cleaned up (or when during topologyChanged), it should consider the time difference between switching from broadcast to non-broadcast attachment points (as they might be previously on two different switches).

Added a DeviceManager REST API. You can use this to see what devices the controller has learned along with their IPs and attachment points.

Conflicts:

	src/main/java/net/floodlightcontroller/devicemanager/internal/DeviceManagerImpl.java

Device manager should implement ITopologyListener to clear out attachment points when topology changes.

(1) Device manager will drop packets (as the first step) if the topology indicates the packet-in port is not allowed for incoming transmissions. (2) Remove a log message from LinkDiscoveryManager. (3) Topology provides a service called isAllowed() that indicates if the port is enabled for incoming and outgoing traffic.  (4) Tests are modified accordingly.

Change device manager to not allow attachment point flapping (there was a bug in the implementation before).  Also, remove some crappy info log from ForwardingBase.

Added a DeviceManager REST API. You can use this to see what devices the controller has learned along with their IPs and attachment points.

Attachment point move suppresion when moving from non-broadcast domain port to broadcast domain port wasn't working. Fixed.