Non-determinism in Bvh::optimize_incremental when restoring from serialized snapshot

[raysplaceinspace]

I originally posted this issue under the Rapier repository, but really the root cause of the issue does come from Parry, and since I want to attempt to fix it I think I should raise an issue here so I can tag against it: dimforge/rapier#910

Bvh::optimize_incremental exhibits non-deterministic behavior if you have the type of application that needs to restore from the state of the Bvh from a serialized snapshot. For example, in my case, I am creating a multiplayer game engine with rollback netcode and so I often need to restore old snapshots of the game state.

The reason is that BvhWorkspace contains significant state that affects the execution of Bvh::optimize_incremental, but BvhWorkspace cannot be serialized (which makes sense!). In particular, the rebuild_frame_index and rebuild_start_index of BvhWorkspace are used to make the subtree optimization continue where it left off each time it is called. These fields cannot be snapshotted but are significant to the execution.

My proposed fix is to move these fields into Bvh itself. Then they will naturally get serialized/deserialized along with the rest of the Bvh. I am going to attempt to make a pull request performing this fix.

This issue occurs on the latest version of parry: 0.26.0.