qa/workunits: mon: auth_caps: cleanup on successful exit

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
qa/workunits: mon: auth_caps: variables must be local

We have variables with the same name that are being shared!  We don't
hit any issues with it currently because the code just kind of works
even though that happens.  Add a bit of new logic that relies on an
immutable return code (for instance) and we're in the woods.

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
mon: AuthMonitor: allow '--force' to skip caps validation

This applies to 'auth get-or-create', 'auth get-or-create-key' and 'auth
caps'.

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
mon: AuthMonitor: skip caps validation for non-mon system

The monitor doesn't really know how to validate caps not meant for it.
The MDS or the OSD may very well allow blank caps for instance, while
the monitor categorically does not.  We can't simply state a capability
is invalid because we wouldn't take it as such.

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
mon: MonCommands: adjust indentation for 'auth add'

Eye-candy.  We changed indentation of a few other entries and this one
was just too darn obvious, itching all over, night terrors, the whole
nine yards.

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
qa/workunits: mon: auth_caps: account for mon blank caps

test creating and entity with blank caps with and without '--force'
being specified.  without '--force' they must fail with EINVAL as the
monitor will not be able to parse them.

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
mon: Monitor: let 'handle_command()' deal with caps validation

If a given client doesn't have the required caps when running a command,
it must receive an EACCES or EPERM reply.  This is already handled by
Monitor::handle_command(), which does an exceptionally good job at it.

Therefore, and unlike other messages that do not expect return values,
we can't simply drop the message if the client doesn't have the
appropriate capabilities, or things can get very weird very fast from
the user's perspective.  Dropping the message for a command without a
reply has roughly the same effect as loss of quorum (timeout, pipes
failing) and confusion may ensue from it.

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>