This class tests operations in MasterRpcServices which require ADMIN access.
It doesn't test all operations which require ADMIN access, only those which get vetted within
MasterRpcServices at the point of entry itself (unlike old approach of using
hooks in AccessController).
There is one big difference between how security tests for AccessController hooks work, and how
the tests in this class for security in MasterRpcServices work.
The difference arises because of the way AC & MasterRpcServices get the user.
In AccessController, it first checks if there is an active rpc user in ObserverContext. If not,
it uses UserProvider for current user. This *might* make sense in the context of coprocessors,
because they can be called outside the context of RPCs.
But in the context of MasterRpcServices, only one way makes sense - RPCServer.getRequestUser().
In AC tests, when we do FooUser.runAs on AccessController instance directly, it bypasses
the rpc framework completely, but works because UserProvider provides the correct user, i.e.
FooUser in this case.
But this doesn't work for the tests here, so we go around by doing complete RPCs.