Limit initial time step to avoid control system deadlocks

[wthrowe]

Proposed changes

Upgrade instructions

Code review checklist

• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.
• The PR lists upgrade instructions and is labeled bugfix or
  new feature if appropriate.

Further comments

[knelli2]

In the BBH metavariables, the InitializeMeasurements action is at the end of the list, so it's fine that we change the step size there. But what prevents somebody from putting another initialization action after it that again changes the step size to something undesirable by the control system? Not saying this needs to hold up this PR, but something we should think about.

[knelli2]

[optional] You could put the if constexpr inside the db::mutate. Avoids the intermediate variable.

[knelli2]

[optional]

  for (const auto& [ab_active, c_active] :
       cartesian_product(std::array{true, false}, std::array{true, false})) {
    test_initialize_measurements<false>(ab_active, c_active);
    test_initialize_measurements<true>(ab_active, c_active);
  }

[wthrowe]

Initialization actions are only allowed to decrease the time step, otherwise they could destabilize the evolution. That won't interfere with this code.

The one exception I could imagine is a hypothetical initial run of some StepChoosers to pick a time step, but that's not really any worse than the existing restrictions on the step action ordering.

[knelli2]

Looks good