Windows: FindObjectInfo refcnt under lock

AFSFindObjectInfo performed the search of Volume object tree protected by
the TreeLock but dropped the lock before incrementing the reference count.
This behavior contributed to a race with the AFSPrimaryVolumeWorkerThread
which has to drop the VolumeCB TreeLock periodically in order to safely
cleanup FCBs.

Reviewed-on: http://gerrit.openafs.org/9719
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 9285cc3d5270306377ef3d6f90468129a8cfd376)

Change-Id: I1eb87bf7eabb9a3c152dfc31ac2727b8970b0b61
Reviewed-on: http://gerrit.openafs.org/9736
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Windows: AFSPrimaryVolumeWorkerThread reorg

Periodically there is a lost race which results in a valid DirectoryCB
with a non-NULL ObjectInformation pointer that refers to freed memory.
This major reorganization simplifies the logic and attempts to close
potential loopholes.

First, the AFSExamineDirectory() function is removed and replaced by
a call to AFSDeleteDirEntry().  The AFSExamineDirectory() function
examined all of the children AFSObjectInfoCB objects which in turn
duplicated much of the logic of AFSExamineObjInfo at the cost of
increased complexity due to the additional layer of locked objects.
Once the AFSDirectoryCB is removed a subsequent pass of the worker
thread will free the AFSObjectInfoCBs.

Second, the AFS_OBJECT_REFERENCE_DIRENTRY category had been used for
both DirectoryCB references and the Pioctl references.  A new
AFS_OBJECT_REFERENCE_PIOCTL category has been created to improve the
ability to track the allocations and releases.

Third, the AFSPrimaryVolumeWorker thread now attempts to hold onto the
VolumeCB TreeLock exclusively.  Previously the lock was held shared.
However, it is not safe for both the garbage collection and the find
routines to both be shared.  One has to be exclusive.  Although holding
the TreeLock exclusively in the garbage collection processing will result
in the lock being held for extended periods of time, it is more likely
that there will be benefits from parallel access during AFSFindObjectInfo()
calls.

Attempts to obtain most other locks are non-blocking.  If the lock cannot
be obtained, the object must be in use.  Therefore, it should not be
garbage collected.

Reviewed-on: http://gerrit.openafs.org/9720
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit ba78ac675c2a90359dedc9cf16e38e6d7e606eaf)

Change-Id: Ia72186a7406f24fe66d2a1dbefe562d91c2c14aa
Reviewed-on: http://gerrit.openafs.org/9737
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>