Realistically, that means the best we can do is:
* Ensure that, at any point in time, any _new_ connections will succeed. There is no period where new connections are dropped.
* Provide some period of time for the old Ztunnel to continue processing any established connections.

If this period of time ("drain period") is longer than any connections, there is zero impact on applications at all.

     * @param period the period between successive executions of the task
     * @since 28.0 (but only since 33.4.0 in the Android flavor)
     */
    public static Scheduler newFixedRateSchedule(Duration initialDelay, Duration period) {
      return newFixedRateSchedule(
          toNanosSaturated(initialDelay), toNanosSaturated(period), NANOSECONDS);
    }

    /**

  }

  @Override
  public final ScheduledFuture<?> scheduleAtFixedRate(
      Runnable command, long initialDelay, long period, TimeUnit unit) {
    return delegate.scheduleAtFixedRate(wrapTask(command), initialDelay, period, unit);
  }

  @Override
  public final ScheduledFuture<?> scheduleWithFixedDelay(
      Runnable command, long initialDelay, long delay, TimeUnit unit) {

   * second" (commonly referred to as <i>QPS</i>, queries per second), and a <i>warmup period</i>,
   * during which the {@code RateLimiter} smoothly ramps up its rate, until it reaches its maximum
   * rate at the end of the period (as long as there are enough requests to saturate it). Similarly,
   * if the {@code RateLimiter} is left <i>unused</i> for a duration of {@code warmupPeriod}, it

  }

  @Override
  public final ScheduledFuture<?> scheduleAtFixedRate(
      Runnable command, long initialDelay, long period, TimeUnit unit) {
    return delegate.scheduleAtFixedRate(wrapTask(command), initialDelay, period, unit);
  }

  @Override
  public final ScheduledFuture<?> scheduleWithFixedDelay(
      Runnable command, long initialDelay, long delay, TimeUnit unit) {

   * second" (commonly referred to as <i>QPS</i>, queries per second), and a <i>warmup period</i>,
   * during which the {@code RateLimiter} smoothly ramps up its rate, until it reaches its maximum
   * rate at the end of the period (as long as there are enough requests to saturate it). Similarly,
   * if the {@code RateLimiter} is left <i>unused</i> for a duration of {@code warmupPeriod}, it

          MYSQL_RANDOM_ROOT_PASSWORD: "yes"
        ports:
          - 9910:3306
        options: >-
          --health-cmd "mysqladmin ping -ugorm -pgorm"
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 10

    steps:
    - name: Set up Go 1.x
      uses: actions/setup-go@v4
      with:
        go-version: ${{ matrix.go }}

			// When an object is locked in compliance mode, its retention mode can't
			// be changed, and its retention period can't be shortened. Compliance mode
			// ensures that an object version can't be overwritten or deleted for the
			// duration of the retention period.
			t, err := objectlock.UTCNowNTP()
			if err != nil {
				internalLogIf(ctx, err, logger.WarningKind)
				return ObjectLocked{}
			}

    for (int i = 0; i < 8; i++) {
      limiter.acquire(); // // #1
    }
    stopwatch.sleepMillis(4500); // #2: back to cold state (warmup period + repay last acquire)
    for (int i = 0; i < 3; i++) { // only three steps, we're somewhere in the warmup period
      limiter.acquire(); // #3
    }

    limiter.setRate(4.0); // double the rate!

    for (int i = 0; i < 8; i++) {
      limiter.acquire(); // // #1
    }
    stopwatch.sleepMillis(4500); // #2: back to cold state (warmup period + repay last acquire)
    for (int i = 0; i < 3; i++) { // only three steps, we're somewhere in the warmup period
      limiter.acquire(); // #3
    }

    limiter.setRate(4.0); // double the rate!