Windows: DOS Device VolumeInfo max name length

In 1.7.2200 the AFS Redirectory began to return

  cellname{%,#}volume

as the volume label in the Volume Information response.  For UNC
paths this is fine but for DOS devices on Windows 7 and earlier returning
a volume label that is longer than the NTFS maximum label length (32
characters) results in the Explorer Shell treating the volume as if it
does not support long file names.

From this patchset forward if the FileObject->FileName indicates that
the query is for a DOS Device, only return the AFS volume name and not the
cell informmation in the Volume Information response.

FIXES 131632

Change-Id: Iff751051bc6f5a3cfdafd569da13fdf68bb6e26b
Reviewed-on: http://gerrit.openafs.org/9751
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-on: http://gerrit.openafs.org/9762
Windows: hold locks during non-cached writes

Writes can alter both the EndOfFile (Fcb FileSize) and the ValidDataLength
which must remain synchronized with the data known to the service.
Dropping the Fcb.Resource and the SectionObjectResource prior to
performing non-cached writes opens the possibility of a race in which
data changes and length updates can be altered independently.

Efforts are made to avoid holding locks across calls to the service
because they can result in deadlocks with object invalidation or extent
management.  However, object invalidation for data version changes are
now handled in a worker thread.  It should be safe to hold onto the
Fcb Resource and SectionObjectResource across non-cached write processing.

The locks are not held in the paging IO path so paging non-cached
writes (which cannot be extending) will not prevent cached writes from
taking place in parallel.

The reason it is critical for the ValidDataLength and the FileSize to
remain in sync with the data for non-paging non-cached writes is that
these values are used to determine whether the Windows cache manager
should trigger a page fault to read data from the service upon receiving
an extending cached write that doesn't fill the page.

Change-Id: I80736daafdb9e6edcc1eeec9a9203fdaad28dfe8
Reviewed-on: http://gerrit.openafs.org/9745
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-on: http://gerrit.openafs.org/9763