Looks fine to me, although I'll admit I've never noticed there was a CLIENT_MAX in this code.
(I wasn't the author.)

Added an inline suggestion related to the man page update.

Assuming you resolve the man page issue that kib@ has commented on, this looks ok to me.

I can't seem to remember how to do inline comments (if I ever knew), so I'll stick it here...

W.r.t. ZFS, I have no idea. It appears that it would need to be a temporary property, but I can't see how/where
those get added?

nfs_dolock() is the front end for the NLM stuff, which I know nothing about.
I'll try emailing dfr@ and see if he can tell me what locking is required.
(You might have noticed that I don't have much use for the NLM;-)

Added an inline comment.

Added two inline comments.

Hmm, not sure. If you look at the code near the end of nfs_advlock() { around line#3100-3120 in head's sys/fs/nfsclient/nfs_clvnops.c } that isn't really
shown in the patch, then where the vnode gets VOP_UNLOCK()'d gets more convoluted. Such as before the lf_advlock() call.
I could do an errout: case so that many of the VOP_UNLOCK(); return(X); cases could become error = X; goto errout; but I'm not sure that
makes the code more readable.
If you think it does make it more readable, let me know and I'll change it.
{ Some like single return points and others don't like goto's. I have no strong opinion w.r.t. this. }

I just ran a test without the timeout in the loop waiting for a connection
attempt and the time it took for a failover was only 1minute more than
with that patch.

The problem is that, without the "timeout" it takes too long for the msleep() to wake up.
The "timeout" or whatever you prefer to call it is meant to set the upper bound on the
time that this loop waits for a TCP connection to complete to approximately
tv.tv_sec (the same timeout as set for SO_SNDTIMEO).

Added comments as kib@ suggested and used tvtohz(), so that tv_usec component is included in timeout.
(I have emailed kib@ one that uses the 1sec timeout and I put that here if he prefers that one.)

I commented inline. I'll admit I don't see spurious wakeup()s will be a problem.
I can (actually already have for the patch I have) include the tv_usec field in
the timeout calculation.
(I'll admit I get nervous fooling with things like time_uptime, which can go
negative in 2038 and assorted things related to overflow.)

Explained inline, but basically timeouts at both places count as one retry
and the RPC attempt fails when the limit on these retries is reached,
so it seems to me that they should be the same amount of time?

I added an inline comment which was basically that I didn't think a timeout of a fraction
of 1sec or setting a timeout of greater than 1sec resolution would be useful.
(My assumption is that normal operation against a slow server could result
in delays of 1sec.)