Fix teardown issue of TCP interconnect
Fix teardown issue of TCP interconnect

Previously, for an interconnect connection, if no data are available at
sender peer, the sender sends a customized EOS packet to the receiver
and disables further send operations using shutdown(SHUT_WR), then
somehow, the sender closes the connection totally with close()
immediately and it counts on the kernel and TCP stack to guarantee the
data been transformed to the receiver. The problem is, on some platform,
if the connection is closed on one side, the TCP behave is undetermined,
the packets may be lost and receiver may report an unexpected error.

The correct way is sender blocks on the connection until receiver
getting the EOS packet and close its peer, then the sender can close
the connection safely.

adam8157/gpdb,xinzweb/gpdb,xinzweb/gpdb,jmcatamney/gpdb,lisakowen/gpdb,adam8157/gpdb,adam8157/gpdb,greenplum-db/gpdb,50wu/gpdb,adam8157/gpdb,jmcatamney/gpdb,adam8157/gpdb,50wu/gpdb,jmcatamney/gpdb,ashwinstar/gpdb,50wu/gpdb,ashwinstar/gpdb,jmcatamney/gpdb,greenplum-db/gpdb,jmcatamney/gpdb,jmcatamney/gpdb,xinzweb/gpdb,50wu/gpdb,xinzweb/gpdb,ashwinstar/gpdb,ashwinstar/gpdb,lisakowen/gpdb,greenplum-db/gpdb,greenplum-db/gpdb,adam8157/gpdb,ashwinstar/gpdb,greenplum-db/gpdb,50wu/gpdb,lisakowen/gpdb,lisakowen/gpdb,lisakowen/gpdb,lisakowen/gpdb,50wu/gpdb,greenplum-db/gpdb,lisakowen/gpdb,xinzweb/gpdb,50wu/gpdb,greenplum-db/gpdb,xinzweb/gpdb,lisakowen/gpdb,adam8157/gpdb,greenplum-db/gpdb,jmcatamney/gpdb,xinzweb/gpdb,50wu/gpdb,ashwinstar/gpdb,adam8157/gpdb,xinzweb/gpdb,ashwinstar/gpdb,ashwinstar/gpdb,jmcatamney/gpdb