HTTP/1 [Response.Body] now automatically drains any unread content upon being
closed, up to a conservative limit, to allow better connection reuse. For most
programs, this change should be a no-op, or result in a performance improvement.
In rare cases, programs that do not benefit from connection reuse might
experience performance degradation if they had been improperly allowing an
excessive amount of idle connections to linger; usually by setting

// and DONE/INTERRUPTED - they have a common ancestor of Runnable.
abstract class InterruptibleTask<T extends @Nullable Object>
    extends AtomicReference<@Nullable Runnable> implements Runnable {
  static {
    // Prevent rare disastrous classloading in first call to LockSupport.park.
    // See: https://bugs.openjdk.org/browse/JDK-8074773
    @SuppressWarnings("unused")
    Class<?> ensureLoaded = LockSupport.class;
  }

        return buildRedirectRequest(userResponse, method, chain)
      }

      HTTP_CLIENT_TIMEOUT -> {
        // 408's are rare in practice, but some servers like HAProxy use this response code. The
        // spec says that we may repeat the request without modifications. Modern browsers also
        // repeat the request (even non-idempotent ones.)

Note that when adding a lazy property to an existing class, you need to check if instances of the class are instantiated via ObjectFactory. Most classes are instantiated this way, but it's possible that a class without any lazy properties was never updated to use it. A tell-tale sign that an object is not instantiated via the ObjectFactory are direct calls to the constructor with new.

### Existing properties in existing classes

   * list of size {@code m x n x p}, its actual memory consumption is much smaller. When the
   * cartesian product is constructed, the input lists are merely copied. Only as the resulting list
   * is iterated are the individual lists created, and these are not retained after iteration.
   *
   * @param lists the lists to choose elements from, in the order that the elements chosen from
   *     those lists should appear in the resulting lists

      int rightCode = identityHashCode(right);
      if (leftCode != rightCode) {
        return leftCode < rightCode ? -1 : 1;
      }

      // identityHashCode collision (rare, but not as rare as you'd think)
      int result = getUid(left).compareTo(getUid(right));
      if (result == 0) {
        throw new AssertionError(); // extremely, extremely unlikely.
      }
      return result;
    }

   * list of size {@code m x n x p}, its actual memory consumption is much smaller. When the
   * cartesian product is constructed, the input lists are merely copied. Only as the resulting list
   * is iterated are the individual lists created, and these are not retained after iteration.
   *
   * @param lists the lists to choose elements from, in the order that the elements chosen from
   *     those lists should appear in the resulting lists

      int rightCode = identityHashCode(right);
      if (leftCode != rightCode) {
        return leftCode < rightCode ? -1 : 1;
      }

      // identityHashCode collision (rare, but not as rare as you'd think)
      int result = getUid(left).compareTo(getUid(right));
      if (result == 0) {
        throw new AssertionError(); // extremely, extremely unlikely.
      }
      return result;
    }

   * of {@code TypeVariable} from {@link TypeResolver#resolveType} will not be able to call {@code
   * getAnnotatedBounds()} on it, but that should hopefully be rare.
   *
   * <p>TODO: b/147144588 - We are currently also missing the methods inherited from {@link
   * AnnotatedElement}, which {@code TypeVariable} began to extend only in Java 8. Those methods

   * @throws IllegalArgumentException if not all services are {@linkplain State#NEW new} or if there
   *     are any duplicate services.
   */
  public ServiceManager(Iterable<? extends Service> services) {
    ImmutableList<Service> copy = ImmutableList.copyOf(services);
    if (copy.isEmpty()) {
      // Having no services causes the manager to behave strangely. Notably, listeners are never