Dynamically set db pool size in Puma

What does this MR do?

Before Puma, we had 1 rails process talk to the database at any given time, which meant a connection pool size of 1 was sufficient to support that model. With Puma and its worker thread pool, there can now be many threads simultaneously trying to talk to the database.

This change makes sure that we allow the db pool size to scale along with the maximum number of worker threads configured. Specifically, we set it dynamically during application start (both CE/EE) to either the maximum number of Puma worker threads or the user specified value, whichever is larger.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

Risks associated with this change:

• we might not configure the pool size in line with customer expectations, as there is an existing db_pool setting customers can use and it might be unclear to them why it doesn't always apply anymore
• I am not sure at the moment what the repercussions are of re-establishing the database connection in an initializer that is executed at a random point in time during application startup. UPDATE: Tested this today by hooking into ActiveRecord::Base#establish_connection and see when it's called and by whom. It looks as that at least as far as initializers go, nothing is calling it before we do now in database_config.rb. This is important since we're recreating the connection pool and don't want to interfere with any possibly ongoing DB I/O.

TODO:

• add unit test? I wasn't sure if we write unit tests for configuration, which seems a bit odd

Closes #32562 (closed)