...in favor of just calling `setException` unconditionally.

I wrote in a code review:

> There's a decent argument that the work we do here and in MoreExecutors.rejectionPropagatingExecutor isn't really buying us much, since it's not clear where else a RejectedExecutionException would be coming from. And even if it is coming from somewhere else, the most plausible location of all the implausible locations is "somewhere after we already called set/setException/setFuture/cancel," in which case we could still call setException(), confident in the knowledge that it will be a no-op.
> 
> Or maybe I'm forgetting something important. Beats me :) But certainly it's hard (impossible?) to write a test that covers this case.
@GwtIncompatible 
  public static ListeningExecutorService newDirectExecutorService() {
    return new DirectExecutorService();
  }
  /**
   * Returns an {@link Executor} that runs each task in the thread that invokes {@link
   * Executor#execute execute}, as in {@code ThreadPoolExecutor.CallerRunsPolicy}.
   *
   * <p>This instance is equivalent to:
   *
   * <pre>{@code
   * final class DirectExecutor implements Executor {
   *   public void execute(Runnable r) {
   *     r.run();
   *   }
   * }
   * }</pre>
   *
   * <p>This should be preferred to {@link #newDirectExecutorService()} because implementing the
   * {@link ExecutorService} subinterface necessitates significant performance overhead.
   *
   *
   * @since 18.0
   */
  public static Executor directExecutor() {
    return DirectExecutor.INSTANCE;
  }
  /**
   * Returns an {@link Executor} that runs each task executed sequentially, such that no two tasks
   * are running concurrently. Submitted tasks have a happens-before order as defined in the Java