Fix couple of concurrency issues in TCP library

TcpServer::AcceptHandlerInternal inserts the new session into the
SesesionMap, releases the mutex and checks if the session has been
closed. If so, it subsequently calls DeleteSession on the session.
This can result in a duplicate delete if the application deletes
the session (by calling DeleteSession or ClearSessions) after the
mutex is released and also returns false from AcceptSession.

Fix is to not insert the session into SessionMap if AcceptSession
returns false.  Just need to make sure that we close the session.
Also ensure that we close the session if we are unable to make it
non-blocking.

TcpServer::ConnectHandler inserts the session into the SesesionMap,
releases the mutex and checks if the session has been closed.  If
so, it erases it from the SessionMap using the iterator returned
by the insert operation.  The iterator may not be valid anymore if
the application deletes the session (by calling DeleteSession or
ClearSessions) after the mutex is released.

Fix is to not use the iterator and instead erase from the SessionMap
by finding the session again.

Change-Id: I6c1754e75e46e29b37fd64fd89a12ffd572fa97e
Make bgp_server_test more robust

Terminate the BgpSessionManager when BgpServer is destroyed instead
of calling ClearSessions directly from ~BgpSessionManager. Doing so
takes care of a deadlock wherein ClearSessions could get called when
a session is being destroyed from a call to DeleteSession.

Make sure that BgpSessionManager does not accept any sessions after
it has called ClearSessions.  Otherwise those sessions get added to
the SessionSet and prevent BgpSessionManager from getting deleted.

Do not delete a BgpPeer till the state machine WorkQueue has been
drained completely.  This prevents an EvTcpDleteSession event from
getting deleted without being processed, hence preventing a leak of
the BgpSession.  The session would otherwise get deleted only when
the BgpSessionManager itself is terminated.

Fix an issue in state machine wherein a BgpOpen received on a stale
session caused a FSM error. A BgpOpen should cause a FSM error only
if it's received on the session currently being used by Established
peer.

Add a few more tests to bgp_server_test. Cleanup to consistently use
counts >= 3 in all tests that wait for specific counters to go up.

Sprinkle const in order make WorkQueue::IsQueueEmpty a const method.

Change-Id: Id1761667d68fe293ab0ddc099db1f508f8504769
Implement more orderly termination of BgpServer

Change-Id: I06152f722561d9af789c253e716c46f3d93993b9
Implement more orderly termination of BgpServer

Change-Id: Ia8341155b7afe943b8c79d06e1530ead143336f2
Implement more orderly termination of BgpServer

Change-Id: I3ad1e01e98d4e133a5fc4f20d8c252cbb94a3018