Non-Sync Plugin types

[james7132]

Objective

When going over #20901, it came across to me that the Sync bound on Plugin might be too strong. There are currently zero uses in first-party crates where we currently rely on Plugin: Sync, or in other words ,we never rely on plugins being simultaneously accessible from multiple threads. Given that most of the plugins we have are ZSTs, this might be too tight of a restriction on plugins that require more configuration (e.g. RemotePlugin).

Solution

Remove the bound on the trait. Utilize that to use Cell instead of RwLock in RemotePlugin.

Given this loosens the restrictions on a core trait, I expect this PR to be, at least, a bit contentious. I currently cannot think of a common use case inside the core App framework for plugins (and Apps that contain them) to be accessed simultaneously from multiple threads.

Testing

Local tests.

[alice-i-cecile]

I can't see any reason why we currently need this bound, nor can I think of any reason why we might want it in the future.

[maniwani]

I don't see plugins being accessed from multiple threads either, but this change might entrench some not-so-good architectural decisions / technical debt.

What if, in the future, you want to represent plugins with entities?

Right now, the "plugin registry" is a couple of fields on SubApp, but those could quite easily be moved into the ECS. Further down that road, consider that if components, systems, and plugins were all represented by entities, components and systems could normally have ChildOf(plugin) and be cleaned up if their plugin is despawned. (Just to state a benefit of doing things this way.)

If y'all eventually decide you want to pursue that, you'd maybe want to walk back this PR. Types currently have to be Send and Sync to be components. If Plugin doesn't require Sync, components wouldn't be able to hold Plugin trait objects without wrapping them in a SyncCell.

---

In general, the particulars of how plugins are stored and handled actually have a lot of subtle, second-order architectural effects.

Plugins being built immediately when you call add_plugins, for example, is a big reason why it's been so hard to move the world out of the winit loop. (Plugins can create !Send data when you build them.) It's also the reason Bevy can't resolve a valid build order automatically. (Plugins are still built in a manually specified order.)