...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.
*
   * @param service the {@code ExecutorService} to shut down
   * @param timeout the maximum time to wait for the {@code ExecutorService} to terminate
   * @param unit the time unit of the timeout argument
   * @return {@code true} if the {@code ExecutorService} was terminated successfully, {@code false}
   *     if the call timed out or was interrupted
   * @since 17.0
   */
  @Beta
  @CanIgnoreReturnValue
  @GwtIncompatible 
  @SuppressWarnings("GoodTime") 
  public static boolean shutdownAndAwaitTermination(
      ExecutorService service, long timeout, TimeUnit unit) {
    long halfTimeoutNanos = unit.toNanos(timeout) / 2;
    
    service.shutdown();
    try {
      
      if (!service.awaitTermination(halfTimeoutNanos, TimeUnit.NANOSECONDS)) {
        
        service.shutdownNow();
        
        service.awaitTermination(halfTimeoutNanos, TimeUnit.NANOSECONDS);
      }
    } catch (InterruptedException ie) {
      
      Thread.currentThread().interrupt();
      
      service.shutdownNow();