salvager: Ignore linktable-only RW volumes

In general, the salvager will try to salvage any volume if we find an
inode for that volume. However, for namei, we'll always have at least
one inode for the RW volume, even if we only have e.g. an RO volume at
a particular site, since the linktable special inode is always marked
as for the RW volume id. So, if we salvage a volume group that only
has an RO, normally we would also try to salvage the corresponding RW,
even if it doesn't exist. We would then recreate the "missing"
metadata files, so after salvaging, the RW appears to exist as a
normal volume.

The salvager currently tries to avoid this by skipping salvaging the
RW if we find more than one volume in the volume group, and if the RW
only has one special inode, and that one special inode is the
linktable. This solves the problem most of the time, but misses a few
corner cases:

 - If we found more than one linktable, we'll try to salvage the RW
   anyway. This shouldn't happen, but certain cases of corruption can
   cause incorrectly-named linktables, resulting in multiple
   linktables.

 - If we only find one volume (the RW), we'll still salvage the RW,
   even if the only inode for it is a single linktable. This can
   happen due to botched salvages in the past, or interrupted deletes
   and such. It's just cruft.

In any situation like those, we cause an RW volume to be created where
there previously was none. This can be a problem, since the RW volume
is unknown to the administrator, and does not appear in the VLDB. Such
"phantom" volumes can be very confusing and can cause problems in the
future. For example, if that same RW volume is moved to the server
with the "phantom" RW volume, we now have two of the same RW volume on
the same server on different partitions, which is a big problem.

So, to avoid these corner cases, check all of the special inodes to
see if all of them are linktables. Also perform this check if we don't
have any non-special inodes (even if we only see 1 volume), to catch
the "cruft" case above.

Change-Id: I00df021ebedce44f69302a48ed2716bd9bda124e
Reviewed-on: http://gerrit.openafs.org/10321
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>