volser: Restore Vol*ListOneVolume error handling

volser: Restore Vol*ListOneVolume error handling

In the 1.4 series, the volserver VolListOneVolume function always
returned success if the specified volume was found in any way, and
ENODEV otherwise. The VolXListOneVolume returned ENODEV if the volume
was not found, or if any error occurred.

DAFS (specifically, commit ed25934c1fe96b143715025b49104e75dce9a361)
changed these so they both behave the same way. That is, they both
return success if the volume was found at all, and ENODEV otherwise.

Commit 53cc2ebaea5e5488d5285f0d13ffa47069ee986f changed both of these
functions so that we always return an error on any attachment error.

These changes mean that a 'vos examine' for a volume with an existing
volume transaction now indicates that a volume is offline/unattached,
but in the 1.4 series, the volume was indicated as "busy".

So, restore the original 1.4 behavior of these functions, so the
volume status is reported as it always was. This effectively reverts
53cc2ebaea5e5488d5285f0d13ffa47069ee986f, and slightly changes the
post-DAFS code to look more like the 1.4 code. This also removes the
'code' variable from VolListOneVolume and adds an explicit comment
about what's going on, to make this a little more clear.

While changing the behavior of VolXListOneVolume to match that of
VolListOneVolume perhaps makes sense, for now just restore the exact
1.4 behavior, and make the function flow look a little more like the
1.4 code did. A future change may make them the same again.

Reported by Andy Malato.

Reviewed-on: http://gerrit.openafs.org/9679
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
(cherry picked from commit 71afa42cdd9107b071fb79f0adaf96c5fcf145da)

Change-Id: I2d7143bf4fde98a11104c5071317a2d2545f41c4
Reviewed-on: http://gerrit.openafs.org/9915
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>