...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.
}
    @Override
    public final boolean isShutdown() {
      return delegate.isShutdown();
    }
    @Override
    public final boolean isTerminated() {
      return delegate.isTerminated();
    }
    @Override
    public final void shutdown() {
      delegate.shutdown();
    }
    @Override
    public final List<Runnable> shutdownNow() {
      return delegate.shutdownNow();
    }
    @Override
    public final void execute(Runnable command) {
      delegate.execute(command);
    }
  }
  @GwtIncompatible 
  private static final class ScheduledListeningDecorator extends ListeningDecorator
      implements ListeningScheduledExecutorService {
    @SuppressWarnings("hiding")
    final ScheduledExecutorService delegate;
    ScheduledListeningDecorator(ScheduledExecutorService delegate) {
      super(delegate);
      this.delegate = checkNotNull(delegate);