re: CBRecall race

Well, I'd have to agree with Saadia, that I can't see a way the server
could alleviate the race between the CBRecall and Open reply with the
delegation in it.

For cases where there hasn't been any Op that uses
the stateid returned to the client in the Open reply when where
it needs to Recall the Delegation, it could introduce a short delay
before issuing the Recall. However, that would only reduce the likelyhood of
the race, not avoid it.

Although I like the idea of certain problems being solved via the transport
layer, I think that requiring bi-directional ordering to be enforced by the
transport layer is overly restrictive. (It also doesn't solve the problem
for 4.0.)

The best I can think of is...
When a client receives a CBRecall request for a stateid it does not
know about:
- for each outstanding Open where a Delegation might be returned in the
  reply (one that don't use a new openowner)
  - compare the CBRecall stateid with any Delegation stateid in the reply
    - if a match
      - reply ok for the CBRecall request and initiate a delegation return
        for that delegation
- return NFS4ERR_BADSTATEID for the CBRecall (in other words, once replies
  to all outstanding Opens at the time the CBRecall was received and no
  match was found)
If there is a way for the client to tell which server the CBRecall is
from and which outstanding Opens apply to that server, it could restrict
the above for loop to those. (If the client happens to know all the