Type mapping plugins and NpgsqlDataSource #2518
Description
#2400 introduced basic support for NpgsqlDataSource in EFCore.PG; that means you can now call UseNpgsql with a data source etc.
However, npgsql/npgsql#4494 is also introducing type mapping plugins and configuration at the data source level, replacing the previous connection-level type mapping support. We should think about how to react to this in EFCore.PG.
Right now, calling UseNodaTime() for EFCore.PG also globally registers the ADO-level NodaTime plugin; this is necessary in order for the traditional approach to work (without data source). Note that it also doesn't work for data source, since it's too late: when UseNpgsql is called, the data source has already been built, and so the global mapping (which is done later) doesn't take effect.
We can simply remove the global ADO mapping from UseNodaTime, and require users to handle things themselves (i.e. add the ADO plugin either to their data source, or globally (which they already need to do with enums)). This would be a breaking change and make things less seamless, but I'm not seeing anything better. Note that this would align plugins with how enums currently work: you have to do the ADO global mapping explicitly before everything else (but with enums you don't also have to add an EF plugin...).
We could also allow users to provide an NpgsqlDataSourceBuilder (instead of an NpgsqlDataSource), allowing us to add the ADO plugin before building the data source. But that's weird (register a NpgsqlDataSourceBuilder in DI??), and opens the question of Build() vs. BuildMultiHost().
On the enum mapping side,EFCore.PG's NpgsqlTypeMappingSource currently uses reflection to see which enums are registered globally. We could maybe improve this by exposing info from NpgsqlDataSource about mapped enums, though we'd still need to support the global mode...