The idea seems generally sane to me, but I would definitely wait for tuexen to pitch in. My understanding is that shutdown() will either progress us somewhat quickly to FIN_WAIT_1 or LAST_ACK depending on our prior state, and the tcp state machine will thereafter deliver the final blow modulo freeing local resources.

It is fine to call soshutdown(..., SHUT_WR), when you know that you don't want to write anymore to the socket, but you want to read from it. This will trigger a state transition to FINWAIT-1 and then FINWAIT-2, if you are in ESTABLISHED and to LAST-ACK and then to CLOSED when you are in CLOSE-WAIT.
Please note that I do not know anything about NFS. But you say you call soshutdown(..., SHUT_WR), when the socket is no longer usable. Based on that description, I'm wondering why you need to keep the socket around locally and can't close it.

In the server side kernel RPC, the socket (struct socket *) is in a
structure called SVCXPRT (normally pointed to by "xprt").
These structures a ref counted and the soclose() is done
when the ref. cnt goes to zero. My understanding is that
"struct socket *" is free'd by soclose() so this cannot be done
before the xprt ref. cnt goes to zero.

For NFSv4.1/4.2 there is something called a back channel
which means that a "xprt" is used for server->client RPCs,
although the TCP connection is established by the client
to the server.
--> This back channel holds a ref cnt on "xprt" until the

 client re-assigns it to a different TCP connection
 via an operation called BindConnectionToSession
 and the Linux client is not doing this soon enough,
it appears.

So, the soclose() is delayed, which is why I think the
TCP connection gets stuck in CLOSE_WAIT and that is
why I've added the soshutdown(..SHUT_WR) calls,
which can happen before the client gets around to
re-assigning the back channel.