Add Compaction Job Min & Max Wait properties

[ddanielr]

Adds a property to configure the max wait interval in the compactor as well as the minimum wait period.

Changes the logic in compaction-coordinator to use this new property when calculating the wait period for sending warning messages

closes #4217

[ddanielr]

Talked with @EdColeman about this PR.
The two main concerns:

1. If the job min and max wait properties were changing the thrift communication call.
   This is not the case as the RetryableThriftCall class uses these options to configure a Retry object.
   

   accumulo/server/base/src/main/java/org/apache/accumulo/server/compaction/RetryableThriftCall.java

   Lines 72 to 83 in f28b55d

   	public RetryableThriftCall(long start, long maxWaitTime, int maxNumRetries,
   	RetryableThriftFunction<T> function) {
   	this.function = function;
   	NeedsRetryDelay builder = null;
   	if (maxNumRetries == 0) {
   	builder = Retry.builder().infiniteRetries();
   	} else {
   	builder = Retry.builder().maxRetries(maxNumRetries);
   	}
   	this.retry = builder.retryAfter(start, MILLISECONDS).incrementBy(0, MILLISECONDS)
   	.maxWait(maxWaitTime, MILLISECONDS).backOffFactor(2).logInterval(1, TimeUnit.MINUTES)
   	.createRetry();

The underlying thrift call is not using these properties and remains unaffected.

2. Not setting maxRetries would leave the compactor in a state where it appeared hung unless a logging level of trace was used.

Attempted to correctly calculate the maxRetries period and pass that value.
Found that the calculation is prone to errors. Opened #4261 to handle that issue separately.

Upon further review, the RetryableThriftCall has logging logic that would display log messages of warn during this infinite wait state. This meets the expectation that the user can determine that the compactor is not hung and is looking for work.