vlserver: Return VL_DBBAD on unhash failure

If we try to delete a vlentry, and the vlentry cannot be found on one
of its hash chains, we cannot unhash the vlentry properly and the
operation fails with VL_NOENT. This results in the following error
messages to the user:

        $ vos delentry 123456
        Could not delete entry for volume 123456
        You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
        VLDB: no such entry
        Deleted 0 VLDB entries

This is confusing, because VL_NOENT can also occur if the user
specifies a volume that does actually not exist. This situation is
indicative of database corruption, usually because of a ubik
transaction that was only half-applied, or because of other ubik bugs
in the past.

The situation can only really be fixed by repairing the database, so
return VL_DBBAD in this case instead, to more clearly indicate that
something is wrong with the database, and not a problem with the
arguments the caller provided.

Change-Id: I6fc275c3ad05c108778f36687227b0a927cca5da
Reviewed-on: https://gerrit.openafs.org/13384
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>

src/vlserver/vlutils.c

@@ -901,6 +901,7 @@ UnthreadVLentry(struct vl_ctx *ctx, afs_int32 blockindex,
 			 aentry->name, blockindex, aentry->volumeId[typeindex], typeindex));
 		VLog(0, ("... The VLDB may be partly corrupted; see vldb_check "
 			 "for how to check for and fix errors.\n"));
+		return VL_DBBAD;
 	    }
 	    return errorcode;
 	}
@@ -913,6 +914,7 @@ UnthreadVLentry(struct vl_ctx *ctx, afs_int32 blockindex,
 		     "hash chain.\n", aentry->name, blockindex));
 	    VLog(0, ("... The VLDB may be partly corrupted; see vldb_check "
 		     "for how to check for and fix errors.\n"));
+	    return VL_DBBAD;
 	}
 	return errorcode;
     }