Merge tcp_usrreq.c:1.167 from HEAD to RELENG_7:

Merge tcp_usrreq.c:1.167 from HEAD to RELENG_7:

  tcp_usrreq.c:1.313 removed tcbinfo locking from tcp_usr_accept(), which
  while in principle a good idea, opened us up to a race inherrent to
  the syncache's direct insertion of incoming TCP connections into the
  "completed connection" listen queue, as it transpires that the socket
  is inserted before the inpcb is fully filled in by syncache_expand().
  The bug manifested with the occasional returning of 0.0.0.0:0 in the
  address returned by the accept() system call, which occurred if accept
  managed to execute tcp_usr_accept() before syncache_expand() had copied
  the endpoint addresses into inpcb connection state.

  Re-add tcbinfo locking around the address copyout, which has the effect
  of delaying the copy until syncache_expand() has finished running, as
  it is run while the tcbinfo lock is held.  This is undesirable in that
  it increases contention on tcbinfo further, but a more significant
  change will be required to how the syncache inserts new sockets in
  order to fix this and keep more granular locking here.  In particular,
  either more state needs to be passed into sonewconn() so that
  pru_attach() can fill in the fields *before* the socket is inserted, or
  the socket needs to be inserted in the incomplete connection queue
  until it is actually ready to be used.

  Reported by:    glebius (and kris)
  Tested by:      glebius

Approved:	re (kensmith)