Limit acquiring namespace read locks to table operations that add/remove tables

**Is your feature request related to a problem? Please describe.**

Currently all fate table operations acquire a read lock on the namespace. This may be unnecessary, it may be safe to only acquire the namespace readlock in table operations that add/remove tables. If it is unnecessary, then its a cost that frequent fate operations like compact or bulk import are paying when they do not need to.

**Describe the solution you'd like**

Limit acquiring the namespace read lock to fate operations that add/remove tables like create table, delete table, import table, and clone table. Remove acquiring the namespace read lock from other table operations like bulk import, compact, etc.

Assuming Accumulo will work like the following then a proof by contradiction is one way to show its correct.

1. The delete namespace gets a write lock on the namespace its trying to delete
2. Table operations that create/delete tables get a read lock on the namespace and write lock on the table.
3. Other table operations only get a read lock on the table.

With the constraints above, assume that a namespace could be deleted while a bulk import fate operation is running on a table in the namespace. This can not happen because the namespace can not be deleted when it has tables (once #5389 is fixed) . The table can not be deleted because the fate op can not get a write lock on the table because the bulk import fate op has read lock on the table.

With this change there would be transitive protection of namespaces being deleted instead of direct protection.

**Describe alternatives you've considered**

None.

**Additional context**

Opened this issue based on conversations in #5334. Marked this as a 4.0 changes as it could be disruptive to make in a bug fix release because namespace locks are persisted in zookeeper. Changing the persisted data related to fate operations in bug fix releases is always tricky and hard to test.

Start with the FATE table operations discussed in #5334 and trace where namespace read locks are acquired for create, delete, import, clone, bulk import, and compact. Compare those lock paths with the stated namespace-deletion constraints, then inspect how persisted ZooKeeper lock data and related tests would need to remain compatible. Done means only table-add/remove operations retain the namespace read lock without allowing unsafe deletion.

Written by the indexing model from the issue text.