Windows: Reset mp/symlink target during fs flush*

When processing a "fs flush*" command, reset the the cm_scache_t
mountPointStringp which contains the known mountpoint or symlink
target information.

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

Change-Id: I6e1b92ad6e9136ff8898d37dd2268b7b0b77cd26
Reviewed-on: http://gerrit.openafs.org/10533
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Windows: Rationalize Freelance vs "fs flush*"

Background:

cm_scache_t objects representing Freelance volume (cell=-1, volume=-1)
are special because they are populated from the Freelance mountpoint
and symlink tables.  These tables are in turn generated from the
registry.  The tables are regenerated on-demand after the execution of
cm_noteLocalMountPointChange() which increments cm_data.fakeDirVersion
which becomes the new data version value for the (-1.-1.1.1) directory
object.

The next time that cm_GetSCache() is called for a Freelance object
the fake root directory is rebuilt by cm_InitFakeRootDir().  Since the
vnode values are not persistent with regards to directory entry names the
FileId unique is used to distinguish the various versions.
cm_data.fakeUnique is incremented with each call to cm_InitFakeRootDir().

Each time cm_noteLocalMountPointChange() is executed the afs redirector is
notified of the data version change which will force the redirector to
rebuild its view of the directory the next time a path evaluation requires
evaluation of the root (\afs).  In other words, on the next request.

If cm_noteLocalMountPointChange() is executed multiple times there is the
possibility of a race between the redirector and the service.  When the
race is lost the redirector receives an invalidation event for -1.-1.1.1
as it is in the process of rebuilding the directory contents.  The
redirector ends up believing it has the most recent data version when it
doesn't but the service no longer has Freelance mountpoint and symlink
tables representing the requested data version.  Hence, the mountpoints
and symlinks end up as CM_SCACHETYPE_INVALID.

fs flushfile and fs flushvolume both had explicit checks to prevent
flushing Freelance objects because each call to cm_FlushFile() on a
Freelance object would execute cm_noteLocalMountPointChange() triggering
the race.

The Problem:

fs flushall is not executed on a specific object (volume or file).
Therefore there was no explicit check to prevent execution against
Freelance objects.  For each cm_scache_t in the cache cm_FlushFile() is
processed.  If there are N Freelance mountpoints and symlinks, there will
be N+1 calls to cm_noteLocalMountPointChange() in quick succession.  Not
only does this risk losing the race described above but it is extremely
wasteful as the Freelance tables may be repeatedly regenerated.

This Patchset:

This patchset re-organizes the Freelance processing in the flush code
paths.  cm_FlushFile() and cm_FlushVolume() can simply no longer be
successfully executed against a Freelance object.  Both will return
CM_ERROR_NOACCESS.

"fs flush <file>" is not permitted against Freelance objects.

"fs flushvolume <path>" will execute cm_noteLocalMountPointChange() once if
the path is a Freelance object.

"fs flushall" continues to execute cm_FlushFile() on all cm_scache_t
objects.  The calls on Freelance object will fail.  After all cm_scache_t
objects are flushed then cm_noteLocalMountPointChange() will be executed
once to force the Freelance directory to be rebuilt.

This patchset does not address the race but significantly reduces the
likelihood the race will be lost.

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

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