Do proper setup/cleanup of MDS exports and client data.

Do proper setup/cleanup of MDS exports and client data.

This also changes the behaviour of MDS connections so that the export
and client data is set up immediately at connect time, rather than at
"getinfo" time.  I am ASSUMING that at recovery time the client does
another connect to the MDS, or that some other mechanism is in place
so that it will get the correct export back (it looks like this is
correct, but I didn't follow the whole code path through for recovery).

I was torn on whether to zap the on-disk MDS client record in the case
where it does a proper disconnect.  In the end I decided against it,
because it was too difficult to pass a parameter to the mds_disconnect()
call telling whether we should zap or not.  We don't want to change the
disk if there is some error in restarting after a failure or if we are
forcibly shutting down the MDS, but only on a clean disconnect by the
client.

So far, the only potential harm that comes from not doing the zapping
of the client record is that we get an (empty) export for each client
that shut down cleanly (and was not overwritten) on the last MDS incarnation.
On the following MDS incarnation this client export will be dropped
because the incarnation number is too low (assuming it remains unused).

Another thing of note is that we pass "struct file *" back to the client
upon open, and dereference this at close time.  We need to move this
into the export struct and pass a cookie to the client (and validate
the cookie) instead of (or in addition to) passing the pointer directly.
This is needed for recovery of the client open state anyways...