...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.
void collectOneValue(int index, @Nullable Object returnValue) {}
  @Override
  void handleAllCompleted() {
    CombinedFutureInterruptibleTask<?> localTask = task;
    if (localTask != null) {
      localTask.execute();
    }
  }
  @Override
  void releaseResources(ReleaseResourcesReason reason) {
    super.releaseResources(reason);
    /*
     * If the output future is done, then it won't need to interrupt the task later, so it can clear
     * its reference to it.
     *
     * If the output future is *not* done, then the task field will be cleared after the task runs
     * or after the output future is done, whichever comes first.
     */
    if (reason == OUTPUT_FUTURE_DONE) {
      this.task = null;
    }
  }
  @Override
  protected void interruptTask() {
    CombinedFutureInterruptibleTask<?> localTask = task;
    if (localTask != null) {
      localTask.interruptTask();
    }
  }
  @WeakOuter