Decouple IContainerListener to avoid parallel computation in cluster

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>