Decouple IContainerListener to avoid parallel computation in cluster

ISSUE: On Container configuration change, or when they register with ContainerManager,
IContainerListener classes are notified locally and on all cluster nodes.
While cluster unaware classes like the Shim classes in the protocol plugin need this
notification on all the nodes to keep their local container related info up to date,
Functional Modules like FRM which are cluster aware do not need to be notified as they
react on these notifications performing flow operations. Currently all the FRMs in the
cluster reacts in parallel on Container Flow changes...

CHANGE: From Container config notification prespective, decouple the cluster aware classes
from the cluster unaware ones having the former register to a new IContainerLocal interface
instead of IContainerListener. On Container config changes, IContainerLocalListener will be
notified only on the controller node on which the configuration was applied (from GUI or NB).
On the remote controllers, where ContainerManager replays the configuration events, only
cluster unaware listeners will be notified.
Also, on IContainerLocalListener registration callback, in contrast with IContainerListener
registration callback, no container configurations bulk update will be pushed.
Simply because the FMs do not need to keep a local container information copy, they do not
care about the past events, they only need to be notified about a live config change event
which they use as a trigger to perform whatever task on their DB. If the task requires the
knowledge of the container config, they directly request it to Container Manager on the fly.

Change-Id: Icbaca58e04d60463b3aa54a61a4a1a467222d18e
Signed-off-by: Alessandro Boch <aboch@cisco.com>
CORS support for ContainerManager Northbound APIs

Change-Id: Iec1f37a249f92e39ede1ff3796b8d88cd2f510f5
Signed-off-by: Madhu Venugopal <vmadhu@cisco.com>
Merge "Decouple IContainerListener to avoid parallel computation in cluster"
Fix bug in FRM

ISSUE: Accessing workOrder mapping providing the wrong key object

Change-Id: I70c704566c6adede3f11348019f0d1da2f7eb43e
Signed-off-by: Alessandro Boch <aboch@cisco.com>
Merge "CORS support for ContainerManager Northbound APIs"
UI: Change TOS to ToS

Change-Id: I2101134e7c3a8333376fdefa84796ed55b1c3827
Signed-off-by: Andrew Kim <andrekim@cisco.com>
Move host refresh related variable from SwitchManager to HostTracker

Change-Id: I30921217c33dd33923cf51e8a24841c744b8b115
Signed-off-by: Maurice Qureshi <maquresh@cisco.com>
Merge "Move host refresh related variable from SwitchManager to HostTracker"
[maven-release-plugin] prepare release releasepom-0.1.0
[maven-release-plugin] prepare for next development iteration
Call the flow programmer synchronously but in a different
thread so that the FRM event handler thread does not get blocked

Change-Id: Ide1e166a15f9619cd9e273feaa8d32a390b5cfb0
Signed-off-by: Asad Ahmed <asaahmed@cisco.com>