Windows: AFSInitDirEntry allocated ObjInfoCBs valid

In AFSInitDirEntry the pattern was to find or allocate an
ObjectInfoCB then destroy it if the DirectoryCB creation fails
for some reason.  The problem with this approach is that once the
VolumeCB ObjectInfoTree.TreeLock is dropped the ObjectInfoCB is findable.
That means that the contents of the ObjectInfoCB must be valid.

This patchset makes three changes.  First, in the case where the
ObjectInfoCB is allocated, the fields of the ObjectInfoCB are populated
from the DirEnumEntry before the TreeLock is dropped.  Second, if the
DirectoryCB allocation fails the ObjectInfoCB is not deleted.  It is
perfectly valid and can be used by a subsequent AFSInitDirEntry call.
Perhaps one that is racing with this thread.   It will eventually be
cleaned up by the AFSPrimaryVolumeWorkerThread.  Finally, when the
ObjectInfoCB reference count is decremented the TreeLock is held shared in
order to prevent races with other threads that might be incrementing it
themselves.

Change-Id: If3091d4fa640bbb614a1a405c3afc910d649aad6
Reviewed-on: http://gerrit.openafs.org/9781
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Windows: AFSInvalidateVolume ObjectInfo refcnt decrement

In AFSInvalidateVolume a reference count is obtained in order to
ensure that the object is valid throughout the invalidation request.
Although the refcnt is obtained while holding the TreeLock the refcnt
was not released while holding the TreeLock which could open the door
for another thread to race.

Change-Id: I5c7ee91b78a2ce5f03cdc5f835b15357ecbec443
Reviewed-on: http://gerrit.openafs.org/9782
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>