Windows: Avoid race during cm_FreeServerList

cm_FreeServerList obtains cm_serverLock exclusively and in some
circumstances will call cm_FreeServer().   cm_FreeServer() will
drop the cm_serverLock if the cm_server_t.refCount is zero in order to
avoid a lock order violation when calling cm_GCConnections() since
cm_connLock is higher in the lock hierarchy.

The call to cm_FreeServer is performed after the cm_serverRef_t
to be deleted is identified but before it is removed from the list.
There is the potential for two threads calling cm_FreeServerList()
to race and for more than one thread to attempt to delete the same
cm_serverRef_t twice.

Fix this by:

1. maintain a private copy of the cm_server_t pointer, delete the
cm_serverRef_t and update the list pointers before calling cm_FreeServer().

2. obtain and release a refcnt on the next cm_serverRef_t to ensure
that it is not deleted out from underneath the thread in case the
cm_serverLock is dropped.

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

Change-Id: I0ee55f76f1af181bc8c3d2ea79aeb76e9f7fa8f6
Reviewed-on: http://gerrit.openafs.org/9556
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Windows: RDR SymbolicLink create support

Permit the redirector to handle Microsoft's IO_REPARSE_TAG_MOUNT_POINT
and IO_REPARSE_TAG_SYMLINK requests.   The IO_REPARSE_TAG_SYMLINK request
is issued as a result of a CreateSymbolicLink Win32 API.

Creating a symlink in Windows is not equivalent to the way a symlink is
created in AFS or UNIX.  Instead of creating a symlink object whose data
string represents the target and mode bits indicate that the stream should
be treated as a link, on Windows it is a two step process.

To create a symlink to a directory, create an empty directory and then
assign the reparse tag data to the directory object.  To create a symlink
to anything else, create an empty file and assign the reparse tag data to
the file.  Deleting a reparse point simply removes the reparse tag data
and not the underlying directory or file.

The way this will work for AFS is that assigning reparse data to an
existing directory or file will require that the object be deleted from
the directory and a new symlink object be created in its place.  This is
why upon successful completion of the upcall to the service the directory
object information has the AFS_OBJECT_FLAGS_DIRECTORY_ENUMERATED flag
cleared.

This patchset permits symlink creation but does not do anything to support
symlink removal.

Symlink target data is not validated.

Reviewed-on: http://gerrit.openafs.org/9424
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
(cherry picked from commit 0cc602a065f5df9959f735ff14e05a6798b9b0b9)

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