Address deadlock scenarios in BGP peer, session mgmt code

Address deadlock scenarios in BGP peer, session mgmt code

In scenario-1, BGPPeer and BGPSessionImpl was acquiring locks in opposite order,
resulting in deadlock. Addressed it by enforcing same order of locking i.e.
[BGPPeer (listener) -> BGPSessionImpl (session)].
In scenario-2, deadlock was because of BGPProtocolSessionPromise and StrictBGPPeerRegistry
acquiring locks in opposite order. Addressed by using concurrent Set obviating
need to acquire lock on StrictBGPPeerRegistry object.

JIRA: BGPCEP-884
Change-Id: I9e05adde3220191c8f8436bd76fb25dbfc251e49
Signed-off-by: Ajay Lele <ajayslele@gmail.com>