Configuring a context with a DbDataSource builder can defeat connection pooling

[roji]

In EFCore.PG, I've added a UseNpgsql overload that accepts an NpgsqlDataSource (instead of a connection string) - that works well and allows a pre-built data source to be used as the source for connections in EF (see npgsql/efcore.pg#2400).

However, that requires users to separately build a data source before calling UseNpgsql, with NpgsqlDataSourceBuilder. Ideally, extension APIs on DbContextOptionsBuilder would allow configuring the NpgsqlDataSourceBuilder, and EF would get the data source from that. In addition, for various type mapping scenarios (type mapping plugins, native enum support...), it should be possible for a DbContextOptionsBuilder to affect the data source, setting up type mapping at the ADO.NET layer (e.g. the EF-layer NodaTime plugin would add the ADO.NET-layer NodaTime plugin to NpgsqlDataSourceBuilder).

This is currently problematic; since OnConfiguring is called for every context instance, a data source would be built for each context instanc, defeating pooling. This doesn't occur when the options are provided externally via the constructor (e.g. DI, context pooling).

A possible way forward would be allow throwing when OnConfiguring is used with APIs that need to modify NpgsqlDataSourceBuilder, forcing the user to switch to externally-provided options instead. Or maybe something else.

[roji]

Team discussion: as a specific solution for the Npgsql problem, it could count the number of NpgsqlDataSources instantiated via the NpgsqlDataSourceBuilder API, and warn/throw when that crosses a certain threshold. This is similar to the service provider error EF itself has.

Opened #29597 for a wider discussion on OnConfiguring and configuration patterns.