...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.
* <pre>{@code
   * b ---- a ---- d
   * |      |
   * |      |
   * e ---- c ---- f
   * }</pre>
   *
   * <p>The behavior of this method is undefined if the nodes, or the topology of the graph, change
   * while iteration is in progress.
   *
   * <p>The returned {@code Iterable} can be iterated over multiple times. Every iterator will
   * compute its next element on the fly. It is thus possible to limit the traversal to a certain
   * number of nodes as follows:
   *
   * <pre>{@code
   * Iterables.limit(
   *     Traverser.forGraph(graph).depthFirstPostOrder(node), maxNumberOfNodes);
   * }</pre>
   *
   * <p>See <a href="https://en.wikipedia.org/wiki/Depth-first_search">Wikipedia</a> for more info.
   *
   * @throws IllegalArgumentException if {@code startNode} is not an element of the graph
   */
  public final Iterable<N> depthFirstPostOrder(N startNode) {
    return depthFirstPostOrder(ImmutableSet.of(startNode));
  }
  /**
   * Returns an unmodifiable {@code Iterable} over the nodes reachable from any of the {@code
   * startNodes}, in the order of a depth-first post-order traversal. This is equivalent to a
   * depth-first post-order traversal of a graph with an additional root node whose successors are