GEODE-9713: Support thread count in ExecutorService rules

[kirklund]

Restores thread count support to ExecutorServiceRule, and adds it to
DistributedExecutorServiceRule.

PROBLEM

ExecutorService rules currently create a newCachedThreadPool which
creates new threads as needed.

Some usages would benefit from the option of specifying a threadCount
limit which would create a newFixedThreadPool that reuses a fixed
number of threads.

SOLUTION

Add optional threadCount creation parameter to both ExecutorServiceRule
and DistributedExecutorServiceRule.

Creating a ExecutorService rule without a threadCount will still create a
newCachedThreadPool. Using a threadCount will now create a
newFixedThreadPool.

[Bill]

Thanks for making this happen @kirklund ! Your knowledge of this framework apparently made this short work for you.

I did make a suggestion about paring down the constructors even further, but this is ok as-is if you disagree with that idea.

[Bill]

This constructor has a lot of parameters. Especially troublesome (for callers) is that it has three-in-a-row of the same type.

I wonder if this class might be improved by making ExecutorServiceRule(Builder builder) the "most general" constuctor, i.e. having other constructors e.g. ExecutorServiceRule(int threadCount) and ExecutorServiceRule() call that one.

If you chose to do that then this constructor would go away. And we'd have (assuming appropriate defaults in the Builder class) e.g.

public ExecutorServiceRule(int threadCount) {
  this(new Builder().threadCount(threadCount));
}

and

  public ExecutorServiceRule() {
    this(new Builder());
  }

Ooh I just noticed this PR almost does this in DistributedExecutorServiceRule! The one change I'd suggest in that class, as here, would be to simply make the builder-taking constructor the most-general constructor and forego the constructor(s) that take the exploded parameter list.

[Bill]

This constructor isn't needed at all. See my comments over on ExecutorServiceRule.

Love how this class' public constructors both call on the builder-taking constructor. It makes those calls very readable.