See #116230.

After some playing around, I found that further exposure of the underlying main loop physics iteration is required to practically use Engine.physics_iteration in a re-simulation context.

This is a heavier-handed approach to manual physics stepping with a few more knobs to tweak. Specifically, this adds the following arguments:

1. increment_frames: Bool
   Defaults to true to retain current behaviour. When true, Engine::_physics_frames is incremented during this physics iteration. This value is reflected in Engine.get_physics_frames(). Passing false does not increment _physics_frames. This argument is useful when re-simulating multiple physics frames during a single "game physics iteration" e.g. during rollback and re-simulation. If _physics_frames is incremented during each frame, input events will appear old despite being received during the current "game physics iteration", thus resulting in e.g. Input.is_action_just_pressed being unexpectedly false.
2. flush_queries_order: Engine.FlushQueriesOrder
   Defaults to Engine.FLUSH_QUERIES_BEFORE_STEP to maintain current behaviour. The main loop currently calls PhysicsServer2/3D.flush_queries before calling physics_process and then PhysicsServer2/3D.step. Passing Engine.FLUSH_QUERIES_AFTER_STEP changes this order to physics_process → PhysicsServer2/3D.step → PhysicsServer2/3D.flush_queries. This is useful when resetting state between physics iterations as it avoids flushing stale queries. Finally, the PhysicsServer2/3D.flush_queries call can be skipped entirely by passing Engine.FLUSH_QUERIES_NEVER.

Additionally, this slightly tweaks the way in which the main loop invokes PhysicsServer2/3D.step. It is now called between PhysicsServer2/3D.sync and PhysicsServer2/3D.end_sync.

Godot's implementation of PhysicsServer uses the internal doing_sync set and unset during sync and end_sync, respectively, to determine when space_get_direct_state and body_get_direct_state may be called only when multithreaded physics is enabled.