Make `TypeRegistry` global available

[afonsolage]

What problem does this solve or what need does it fill?

bevy_reflect uses TypeRegistry to keep track of metadata used to dynamic interact with Reflect types. This is also used by ser/de operations, like bevy_scene and any networking.

Users should keep a reference to a single TypeRegistry that contains all types registered and pass it around to Scenes, ReflectSerializer, *ReflectDeserializer and any type which needs to deal with its metadata, which is very verbose to carry around.

Also this make it hard to have custom ReflectSerialize and ReflectDeserialize implementations, since there is no TypeRegistry available, where in this case, users should make the TypeRegistry global available themselves.

Usually the TypeRegistry is written once, at the App startup, either by plugins or by any custom logic, and then read by any bevy_reflect operations which needs to know it's metadata.

What solution would you like?

Add a default global available TypeRegistry, to be used when a single TypeRegistry is required (which should cover most use cases), but keep TypeRegistry to be instantiated and be used individually when required (something like ReflectSerializer::with_registry).

1. Make TypeRegistry global available;
2. Change ReflectSerializer/*ReflectDeserializer; to use global TypeRegistry by default;
3. Add an option to use a custom TypeRegistry on:
   1. ReflectSerializer;
   2. *ReflectDeserializer;

What alternative(s) have you considered?

Let users create a global available TypeRegistry, to be built after app startup and use it. This will solve the problem of accessing TypeRegistry inside a custom ReflectSerialize/ReflectDeserialize but keeping the verbosity of carrying around the TypeRegistry.

Additional context

I'll do some researches on this subject, but there are some questions which needs to be solved, mostly to know how far should we go with this enhancement:

• 1. Should we change DynamicScene to also use global TypeRegistry by default?
• 2. Should we remove the App::register_type in favor of a static TypeRegistry::register_type?
• 3. Should we remove the resource TypeRegistry from App?

Also, another questions to be answered:

• 1. There are some use cases where multiple TypeRegistry should be kept around?
• 2. There are some use cases where new types will be registered, after the app startup stage?

[MrGVSV]

2. Should we remove the App::register_type in favor of a static TypeRegistry::register_type?

One of the foreseeable complications with this is the performance of acquiring a write lock on the registry every time we need to register types and type data.

Maybe we remove App::register_type like you suggest but, along with a single-use TypeRegistry::register_type, we could include TypeRegistry::register_scope:

TypeRegistry::register_scope(|registry| {
  // Only need to get the lock once
  registry.register::<Foo>();
  registry.register::<Bar>();
  // ...
});

[cart]

I'm almost always against globals, especially for "logical constructs" because they disallow app-specific config in a context where there are multiple apps at the same time. They also complicate (and sometimes break) things like unit tests, which we're already seeing the consequences of from #2250.

I don't think optimizing the ergonomics of internal serializers is worth that loss of flexibility. Forgive me for throwing in a slippery slope argument, but if we are willing to make this call here, it feels like we could justify globals for pretty much everything.

Then theres @MrGVSV's point about threading. We've already solved this problem via the Resource abstraction (in combination with systems). I think we should let Bevy do its thing here.

And we've already optimized the type registration ergonomics from the users' perspective. Accessing the type registry for type registration is fully abstracted out.