vol: Avoid getting stuck in ATTACHING in attach2

Since commit 5fc2365f, a VNOVOL error early in attach2 meant that we
skipped changing the volume state to anything, and just returned
instead. When we do this, the volume is in VOL_STATE_ATTACHING for
DAFS, and so if we return, the volume will forever be in
VOL_STATE_ATTACHING. The next thing that tries to access the volume
will wait forever for the volume to come out of that state.

So, revert half of 5fc2365f, and transition to ERROR state instead.
This code path should not be hit during normal usage, since a
nonexistant volume access for the fileserver will be detected earlier.
If the volume does not appear to exist at this stage of attachment,
something is wrong with the volume, so this warrants the ERROR state.

For the volserver and other volume utilities, we may hit this when a
request just plain references a nonexistant volume for whatever
reason, but in that case the vp should go away soon. For non-DAFS,
this commit does not change much, since the difference between
error_notbroken and unlocked_error is very small.

The other half of 5fc2365f is not changed, since it is correct. For
VOFFLINE errors at this point, the volume has already been
transitioned to VOL_STATE_UNATTACHED, so it is okay to return. Add a
comment to help make this more explicit.

Reviewed-on: http://gerrit.openafs.org/7516
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit 4f9c3f2be9abd5548dd52888b49c407d574b6557)

Change-Id: I8e2b9d2a114f8aea283145ca44bf8ae52c354908
Reviewed-on: http://gerrit.openafs.org/9482
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>