PoC: implement one connection pool for all tenants

Currently RMB uses one connection pool per tenant. The DB_MAXPOOLSIZE env variable sets the pool size, the default is 4, folio-ansible sets it to 5.

GBV runs a multi-tenant installations with 18 tenants, the number of GBV's tenant will increase significantly.

The number of database connections is (number of tenants) * (number of modules with direct database access) * DB_MAXPOOLSIZE.

This results in hundreds or thousands of database connections that occupy resources. This slows down all connections, even idle connections slow down other connections, for details see https://www.citusdata.com/blog/2020/10/08/analyzing-connection-scalability/

A key architectural principle of a multi-tenant software is resource sharing across the tenants. Therefore a module should reuse a database connection for all tenants.

This is to provide better scalability and avoid issues like RMB-663

To ensure tenant separation the implementation should respect tenant authorization role and use set role/set session authorization when retrieving connections from the pool, see FOLIO-1794. If there are multiple idle connections in the pool the implementation should prefer a connection that already has the desired tenant authorization to avoid the round-trip for changing the tenant authorization.

The new implementation should be an option, not a replacement of the old implementation. Use an env variable like DB_MAXSHAREDSPOOLSIZE to select the new implementation.

At this time we cannot give SysOps of multi-tenant installations an advice how to choose DB_MAXSHAREDSPOOLSIZE. https://github.com/folio-org/mod-licenses/search?q=maxpoolsize already uses a shared pool and uses a pool size of 50.

What we expect:

• Reduced number of database connections.

• Less database memory usage.

• Better database performance because of reduced number of idle database connections.

• Faster response time when no idle database connection of the same tenant is available because switching the tenant authorization of an idle database connection of some other tenant to the current tenant is faster than creating a new connection.

• In same cases slower response time due to switching the tenant authorization role, the switching is not needed in the old implementation.