Fix stale occlusion culling components

[kristoff3r]

Objective

Fixes #23108

When occlusion culling gets disabled for a view we didn't clean up the generated components, which caused some later occlusion culling systems to run in an invalid state.

This problem was discovered recently, and while I haven't bisected it my guess is that it's been present since the retained render world. We could really use a more general approach to catching and/or preventing these issues with stale resources.

Solution

Remove stale resources in the prepare system before we make new ones.

Testing

cargo run --example occlusion_culling and press space a couple of times.

[ChristopherBiscardi]

nice. I have confirmed that the previous validation warning (for downsample multisample depth bind group) no longer shows when switching between on/off in the occlusion culling example on macos.

[beicause]

How about using #[extract_component_sync_target(Self, ViewDepthPyramid, ViewDownsampleDepthBindGroup)] which is added in #23334

[kristoff3r]

How about using #[extract_component_sync_target(Self, ViewDepthPyramid, ViewDownsampleDepthBindGroup)] which is added in #23334

I gave it a shot, but it's not trivial. The OcclusionCulling component is in bevy_render and the others are in bevy_core_pipeline, so it's not possible to use the macro. I could try to use SyncComponentPlugin manually, but I would have to move the ExtractComponentPlugin out of bevy_renders view module into MipGenerationPlugin to make the trait implementations to line up, which I think would silently break third party users.