Investigate replacing long+TimeUnit with Duration in more places

**Is your feature request related to a problem? Please describe.**
No problem. It seems like a nice improvement to replace methods that accept a long and a `TimeUnit` with a single `Duration` parameter.

Looking through the code I see the following methods that have this pattern of long+TimeUnit:
EDIT: crossed out ones that we shouldnt change
* ~~ScannerBase.setTimeout(long timeOut, TimeUnit timeUnit)~~
* ~~ScannerBase.setBatchTimeout(long timeOut, TimeUnit timeUnit)~~
* ~~BatchWriterConfig.setMaxLatency(long maxLatency, TimeUnit timeUnit)~~
* ~~BatchWriterConfig.setTimeout(long timeout, TimeUnit timeUnit)~~
* ~~ConditionalWriterConfig.setTimeout(long timeout, TimeUnit timeUnit)~~
* ~~DelegationTokenConfig.setTokenLifetime(long lifetime, TimeUnit unit)~~
* TabletLogger.suspended(KeyExtent extent, HostAndPort server, long time, TimeUnit timeUnit, int numWalogs)
* ThreadPools.createFixedThreadPool(int numThreads, long timeOut, TimeUnit units, final String name, boolean emitThreadPoolMetrics)
* ThreadPools.createThreadPool
* ~~MiniAccumuloCluster.stopProcessWithTimeout(final Process proc, long timeout, TimeUnit unit)~~
* TestTicker.advance(final long value, final TimeUnit units)

There is a good chance that a lot of these should stay as they are or are not worth looking into but it seems like this could be a good improvement for some. I think each would need to be investigated to see how these values are used and if there are reasons why we might want to avoid `Duration`.

Review the remaining candidates in TabletLogger.suspended, ThreadPools.createFixedThreadPool/createThreadPool, and TestTicker.advance, starting with their current callers and how the timeout values are used. Done means identifying which methods should use Duration, documenting reasons to keep the others unchanged, and updating affected callers and tests where a conversion is justified.

Written by the indexing model from the issue text.