Do `so_rcv' cleanup with sblock() held.

Do `so_rcv' cleanup with sblock() held.

solock() should be taken before sblock(). soreceive() grabs solock() and
then locks `so_rcv'. But later it releases solock() before call uimove(9).
So concurrent thread which performs soshutdown() could break sorecive()
loop. But `so_rcv' is still locked by sblock() so this soshutdown()
thread will sleep in sorflush() at sblock() call. soshutdown() thread
doesn't release solock() after sblock() call so it has no matter where to
release `so_rcv' - is will be locked until the solock() release.

That's why this strange looking code works fine. This sbunlock() movement
just after `so_rcv' cleanup  affects nothing but makes the code
consistent and clean to understand.

ok mpi@