Add query limiter caching layer

[lbschanno]

Overview

Add a caching layer to the query limiter feature. The caching layer is primarily encapsulated within two classes, QueryLogicCache.java, and QueryCountsCache.java. These classes leverage CuratorCaches to listen for node creation/deletions, and upon receiving them, update local collections maintained in memory.

These caches also register listeners to listen for changes to the connection state of the backing Zookeeper client. If the client ever reaches a SUSPENDED, LOST, or READ_ONLY state, the caches will automatically be marked unhealthy, and query limit enforcement will be suspended. If the client later reaches a state of RECONNECTED, the caches will be rebuilt to be put back into a healthy state, and query limit enforcement will resume.

Closes #3643

Testing

Via datawave quickstart, I deployed branches integration and task/queryLimiterCaching to measure and compare the speed of QueryLimiter.checkForLimits(). The QueryLimiter was configured such to ensure worst case of needing a full traversal of all active query nodes in Zookeeper to obtain a current count. I also manually generated and added non-ephemeral versions of active query nodes in Zookeeper to simulate high numbers of active concurrent queries.

All times measured below represent averages from batches of 25 randomized queries.

Branch integration:

Simulated Active Queries	Time
0	2ms, 303860ns
5000	2ms, 098482ns
50000	2ms, 323304ns

Branch task/queryLimiterCaching:

Simulated Active Queries	Time	Improvement Factor
0	0ms, 117585ns	19.59
5000	0ms, 101900ns	20.59
50000	0ms, 121987ns	19.04

On average, the caching layer made checking for limits around 20x faster on a quickstart deployment.