* the following strategies:
 *
 *  1. If the current call already has a connection that can satisfy the request it is used. Using
 *     the same connection for an initial exchange and its follow-ups may improve locality.
 *
 *  2. If there is a connection in the pool that can satisfy the request it is used. Note that it is
 *     possible for shared exchanges to make requests to different host names! See

// - List of Smart Object Storage protocol capabilities supported by the server.
// Currently, there are three capabilities supported:
//   - Capacity Reporting
//   - Backup data locality for upload sessions (Veeam Smart Entity)
//   - Handover of IAM & STS Endpoints instead of manual definition in Veeam Backup & Replication. This allows Veeam
//     Agents to directly backup to object storage.
//

   * There is no need for a blocking lock; when the lock is not
   * available, threads try other slots (or the base).  During these
   * retries, there is increased contention and reduced locality,
   * which is still better than alternatives.
   *
   * Per-thread hash codes are initialized to random values.
   * Contention and/or table collisions are indicated by failed

 * </ul>
 *
 * <p>Advantages compared to {@link com.google.common.collect.ImmutableList ImmutableList}{@code
 * <Long>}:
 *
 * <ul>
 *   <li>Improved memory compactness and locality.
 *   <li>Can be queried without allocating garbage.
 *   <li>Access to {@code LongStream} features (like {@link LongStream#sum}) using {@code stream()}
 *       instead of the awkward {@code stream().mapToLong(v -> v)}.

 * </ul>
 *
 * <p>Advantages compared to {@link com.google.common.collect.ImmutableList ImmutableList}{@code
 * <Integer>}:
 *
 * <ul>
 *   <li>Improved memory compactness and locality.
 *   <li>Can be queried without allocating garbage.
 *   <li>Access to {@code IntStream} features (like {@link IntStream#sum}) using {@code stream()}
 *       instead of the awkward {@code stream().mapToInt(v -> v)}.
 * </ul>

## Version 4.4.1

_2020-03-08_

 *  Fix: Don't reuse a connection on redirect if certs match but DNS does not. For better
    locality and performance OkHttp attempts to use the same pooled connection across redirects and
    follow-ups. It independently shares connections when the IP addresses and certificates match,

    // The Dolphin algorithm is attractive because it does the fewest array reads and writes: each
    // array slot is read and written exactly once. However, it can have very poor memory locality:
    // benchmarking shows it can take 7 times longer than the other two in some cases. The other two
    // do n swaps, minus a delta (0 or 2 for Reversal, gcd(d, n) for Successive), so that's about