Tracking issue: eliminate or explicitly silence all Bevy-internal execution order ambiguities

[alice-i-cecile]

@alfonsolage and I have made the system execution order ambiguity detector significantly more user-friendly in #4299.

As a result, I think it's now worth pushing towards internal determinism as a goal (for the reasons laid out in #2480).

At the time of writing, there are 54 pairs of ambiguities (full list in next comment), split across two stages: CoreStage::PostUpdate and RenderStage::Extract. These are most usefully divided into true positives (which represent genuine bugs and require explicit ordering) and false positives (which should either be explicitly ignored or have their data access tweaked).

True positives

• flex_node_system conflicts with parent_update_system on ["Children"]
• ui_z_system conflicts with parent_update_system on ["Children"]
• camera_system<OrthographicProjection> conflicts with assign_lights_to_clusters on ["Camera"]
• camera_system<OrthographicProjection> conflicts with update_frusta<OrthographicProjection> on ["OrthographicProjection"]
• assign_lights_to_clusters conflicts with various update_frusta systems on ["Frustum"]
• check_visibility conflicts with update_directional_light_frusta on ["Frustum"]

False positives

• change_window, play_queued_audio_system<AudioSource> and add_clusters
  • None of these should be exclusive systems ([Merged by Bors] - Converted exclusive systems to parallel systems wherever possible #2774), but don't clash internally
• text_system, image_node_system, camera_system, text_2d_system: clashing on Assets<Image>
  • we don't really care what order those run in.
• camera_system<OrthographicProjection> conflicts with camera_system<PerspectiveProjection> on ["Camera"] (and the same for update_frustra)
  • these queries should be disjoint
• extract_cameras and extract_lights conflict on VisibleEntities
  • this seems to just want stricter query filtering
• many extraction systems conflict on RenderWorld
  • extract_sprites, extract_clear_color, extract_cameras, extract_windows, extract_uinodes, extract_shaders, extract_text_uinodes, extract_text2dsprite, extract_sprite_events
  • these all seem to have disjoint data access, but because it's within a subworld, we can't represent this to the scheduler correctly
  • [Merged by Bors] - Make RenderStage::Extract run on the render world #4402 should help address this, even though it's not the main goal

[JoJoJet]

What's the state of this issue? I think most of these points have been resolved by now.

[alice-i-cecile]

Yep I'm calling this resolved.