Fix bug in XmppChannel close that causes an assert to fail later.

If the vrf_membership_request_map_ is non-empty when XmppChannel
close is started, but the routingtable_membership_request_map_ is
empty, the close of the XmppPeer is not deferred.  If a routing
instance that's in the vrf_membership_request_map_ subsequently
gets created before the XmppPeer close process is complete, one
or more RTarget routes for the routing instance are published and
registration for the tables in the instance is triggered. These
routes cause an assertion to fail when the XmppPeer is destroyed.

Following changes are implemented to address this problem.

- Clear vrf_membership_request_map_ when XmppChannel close starts
- Ignore RoutingInstance callback if XmppChannel is closing
- Do not add a RTarget route if XmppChannel is closing
- Flush the defer_q_ on XmppChannel close

Add assertion that a BgpPath from a down peer cannot be inserted.
Do not replicate BgpPaths from a down peer.
Rename defer_close_ to defer_peer_close_ to clarify it's purpose.

Add test to bgp_xmpp_deferq_test.cc for the scenario in question.
Make TearDown more robust by waiting for queues to be empty.