The SO_NOSIGPIPE socket option allows a user process to mark a socket

The SO_NOSIGPIPE socket option allows a user process to mark a socket
so that the socket does not generate SIGPIPE, only EPIPE, when a write
is attempted after socket shutdown.  When the option was introduced in
2002, this required the logic for determining whether SIGPIPE was
generated to be pushed down from dofilewrite() to the socket layer so
that the socket options could be considered.  However, the change in
2002 omitted modification to soo_write() required to add that logic,
resulting in SIGPIPE not being generated even without SO_NOSIGPIPE when
the socket was written to using write() or related generic system calls.

This change adds the EPIPE logic to soo_write(), generating a SIGPIPE
signal to the process associated with the passed uio in the event that
the SO_NOSIGPIPE option is not set.

Notes:

- The are upsides and downsides to placing this logic in the socket
  layer as opposed to the file descriptor layer.  This is really fd
  layer logic, but because we need so_options, we have a choice of
  layering violations and pick this one.

- SIGPIPE possibly should be delivered to the thread performing the
  write, not the process performing the write.

- uio->uio_td and the td argument to soo_write() might potentially
  differ; we use the thread in the uio argument.

- The "sigpipe" regression test in src/tools/regression/sockets/sigpipe
  tests for the bug.

Submitted by:		Mikko Tyolajarvi <mbsd at pacbell dot net>
Talked with:		glebius, alfred
PR:			78478
MFC after:		1 week