Some AccumuloClient API operations do not require an authenticated user

Issue #3427 highlighted the fact that some API operations do not require the client to have been constructed using an authenticated users. In the case of a bug, this could happen because the RPC endpoint doesn't authenticate the user correctly. Those cases should absolutely be fixed. However, there are also cases where this occurs because the operation is a ZooKeeper-only operation, and does not require communicating with an Accumulo service. The example in #3427 was the ability to list tables, but there may be others (list namespaces, etc.)

Even if authentication is added to the Accumulo code to perform these operations, the information is still visible in ZooKeeper using zkCli.sh or another ZK client, because they are world-readable.

This issue is to propose:
1. identifying those operations where authentication isn't currently needed,
2. consider the impact of locking down the information in ZK so they are not world-readable, and
3. adding an authenticated RPC endpoint in Accumulo services to perform the operation for the client, and changing the client implementation to use that RPC endpoint instead of talking directly to ZK.

Start by reviewing issue #3427 and auditing AccumuloClient operations such as listing tables and namespaces to identify which communicate only with ZooKeeper. Compare their behavior with zkCli.sh and examine whether the information is world-readable. Done means the affected operations, ZooKeeper locking impact, authenticated RPC requirements, and client changes are documented and agreed.

Written by the indexing model from the issue text.