XBSD: do not claim AFS_VM_RDWR_ENV

XBSD: do not claim AFS_VM_RDWR_ENV

The AFS_VM_RDWR_ENV configuration parameter (defined or not defined
in each platform's param.h) is undocumented, but appears to be an
indication of a property of the platform OS's VFS layer, or perhaps just
of the complexity of the read/write vnops that we implement for it.
That is, AFS_VM_RDWR_ENV is defined when the read/write vnops implement
partial write logic (and presumably when they interact with the OS VM
layer in ways not expressed by the afs_write() abstraction); systems
that do not define AFS_VM_RDWR_ENV can use the afs_write() function
fairly directly as the vnode operation.  Use of AFS_VM_RDWR_ENV
evolved over time, with the original (AFS 3.2/3.3-era) code using a
simple scheme that handled partial writes directly in afs_write()
and avoided complexity in callers. In AFS 3.4, sunos and solaris
gained a more complicated read/write vnop that incorporated the
afs_DoPartialWrite() call itself, and eventually in 3.6 we see the
behavior established at the original IBM import, with all the (Unix)
OSes supported at that time defining AFS_VM_RDWR_ENV.

When DARWIN support was brought in in commit
a41175cfbbf4d06ccfe14ae54bef8b7464ecd80b, its param.h properly did
not define AFS_VM_RDWR_ENV, as OS X uses a VFS interface that shares
some level of abstraction with the traditional BSD VFS and its
read/write/getpages/putpages operations, so the afs_write() behavior
was natural and no extra complications needed for integration with the
VM layer or other optimizations.

However, when the initial FreeBSD support came in a few months later,
it seems to have taken inspiration from the OSes that were supported
in the initial IBM import, and kept the AFS_VM_RDWR_ENV definition.
This was then propagated to all the later BSDs as they were added.

Perhaps the most noticeable consequence of this definition is that
the calls to afs_DoPartialWrite() from afs_write() are bypassed, with
a comment that "[i]f write is implemented via VM, afs_DoPartialWrite()
is called from the high-level write op" (and calls to afs_FakeOpen()
and afs_FakeClose() are similarly skipped).  This means that attempting
to write a file larger than the local cache will hang waiting for
more space to be freed, which will never happen as the vcache remains
locked and will not be written out in the background.

In the absence of a documented meaning for AFS_VM_RDWR_ENV, this
also gives us a proxy that can be used to indicate whether a given
OS's support intended to claim the AFS_VM_RDWR_ENV -- such platforms
will actually contain the call to afs_DoPartialWrite() in the
appropriate vnode operation.  This can be used to sanity-check the
places where AFS_VM_RDWR_ENV is removed by this commit.  Interestingly,
HP-UX does not call afs_DoPartialWrite() but also is clearly in a VFS
that uses a rdwr()-based approach, as the corresponding vnode operation
is implemented by mp_afs_rdwr(), so leave it unchanged for now.

Tim Creech is responsible for noting the lack of calls to
afs_DoPartialWrite() on FreeBSD, and Chaskiel Grundman for the
historical research into pre-OpenAFS AFS behavior.

Designing and implementing more complicated BSD read/write vnops that
incorporate afs_DoPartialWrite() and other improvements is left for
future work.

Change-Id: I8e89855ac31303934f97d0753b64899fb7e3867c
Reviewed-on: https://gerrit.openafs.org/12520
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Antoine Verheijen <apv@ualberta.ca>
Reviewed-by: Tim Creech <tcreech@tcreech.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>