The reset-state implementation in the client shell has a few issues
that merit cleaning up:

We have and are adding an <x>-reset-state operation for many objects
in Cinder. This results in numerous commands when we could consolidate
these into one command. Consolidating things into a single command
makes more sense because this is intended to be a rarely-used admin
fix-up tool, and not a prominent feature of our client.

The current reset-state model also defaults to unsafe behavior. It
will reset an object to “available” if a user runs it on an object
without other parameters. This is not a safe path to use as a default
because we have no way to know if the object is actually in an
“available” state and resetting it to “available” will result in odd
problems later.

This is trickier to keep from breaking compatibility, but worthwhile.
The defaulting is done in the client. We could handle this by adding
a stricter check in the client using the microversion checks, so that
using microversion 3.30+ requires the user to specify the desired
state, but when using older API versions, the previous behavior
is kept. This does not correspond with an actual API change
on the server, but should work as a way to handle compat here.

Decide that we will no longer add <x>-reset-state operations to
the client shell.

(Optional:) We should consider looking at attach-status and

migration-status resets as well. These are required to be specified
manually but there may be cases where it would be more consistent
to handle this for the caller.

i.e. does it ever make sense to reset a volume to “available” and not
clear its attach status?