OK, I think this is more or less ready for review.

Note that we don't yet use the recently-merged DbDataSource from runtime. Instead of have a compatibility-shim DbDataSource for older TFMs (as we usually do), and use that for all TFMs for now. Once we take a dependency on a .NET 7.0 preview which contains DbDataSource, we'll use that one.

Thanks for the review @vonzshik!

The thing I'm the most unsure of is that NpgsqlDataSource is a subclass of DbDataSource: there is already quite a bit of code in our pooling implementation, and adding even more things there (as creating connections, commands and batches) seems a bit too much for me.

I understand what you're saying. First, there's going to have to be an NpgsqlDataSource which is a subclass of DbDataSource: that's where users would find the Npgsql-specific APIs for configuring the data source (logging, auth...). Now, that doesn't mean that this hierarchy must be the same as the internal one we have for pooling/multihost/multiplexing... In fact, when I started I thought that NpgsqlDataSource would have a a reference to one of the "connector source" types (as they're currently named), rather than have the same hierarchy. But it seemed needlessly complicated and just another layer of indirection, so I ended up merging them. It's also important to note that NpgsqlDataSource itself (the abstract base class) is pretty thin, and all the heavy pooling stuff is in the subclasses. So it feels to me that code is still well-factored in the hierarchy.