Allow multiple in-network services in chain to be on 1 vRouter

Problem:

If 2 in-network service instances that are part of the same chain get
instantiated on the same compute node, service chaining does not work
correctly.  ServiceChain routes for only one of the service instances
get adverrtised as L3VPN routes.  This is the case for both the left
and right routing instances of each service instance.

Cause:

The root cause is a design issue in the service chaining code in the
case of multiple in-network services. The RD for ServiceChain routes
gets generated based on IP Fabric address of the agent advertising
the connected route and the VRF id of the agent in default RI for the
left and right VNs of the servcie chain. Since the VRF id used is from
the default RI and not the service RI, the RD for ServiceChain routes
from both instances is the same.  Hence we end up with 2 paths for the
same L3VPN routes instead of 2 different L3VPN routes.  Consequently,
only one of the patsh gets advertised to other peers via BGP.

Fix:

Fix is to generate the RD for ServiceChain routes based on VRF id of
the agent for the service routing instance into which the ServiceChain
route gets added.  Also take care of race conditions where the CN may
have received the connected route from agent, but the agent has not
yet subscribed to the service chain routing instance. This is done by
updating all ServiceChain routes for a service routing instance when
an agent subscribes or ubsubscribes to it.

Pending:

If a connected route is originated from XMPP, CN needs to only use the
XMPP route to generate a path for the ServiceChain route.  Information
from BGP routes advertised by other CNs as a result of exporting the
XMPP route should not be used to generate path for ServiceChain route.
This will be addressed via a separate commit.

Change-Id: I214ace1966f9bb4ca16c1fe80799a4c0d15926de
Partial-Bug: 1374114
Merge "Allow multiple in-network services in chain to be on 1 vRouter" into R1.10