...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
    final void afterRanInterruptibly(T result, Throwable error) {
      /*
       * The future no longer needs to interrupt this task, so it no longer needs a reference to it.
       *
       * TODO(cpovirk): It might be nice for our InterruptibleTask subclasses to null out their
       *  `callable` fields automatically. That would make it less important for us to null out the
       * reference to `task` here (though it's still nice to do so in case our reference to the
       * executor keeps it alive). Ideally, nulling out `callable` would be the responsibility of
       * InterruptibleTask itself so that its other subclasses also benefit. (Handling `callable` in
       * InterruptibleTask itself might also eliminate some of the existing boilerplate for, e.g.,
       * pendingToString().)
       */
      CombinedFuture.this.task = null;
      if (error != null) {
        if (error instanceof ExecutionException) {
          CombinedFuture.this.setException(error.getCause());
        } else if (error instanceof CancellationException) {
          cancel(false);
        } else {
          CombinedFuture.this.setException(error);
        }
      } else {
        setValue(result);
      }
    }
    abstract void setValue(T value);
  }
  @WeakOuter