Configure and enforce max connections per user at runtime

[Justin-Kwan]

Description

This PR introduces a new command to enforce max user connections at runtime. In addition to existing max_user_connections per user on pgbouncer.ini file reload, PgBouncer operators can now execute SET USER <user> = 'max_user_connections=<new limit> pool_mode=<session|transaction|statement>' to update a user's max connections across all pools that the user is in.

When the pgbouncer.ini file is reloaded, or the above command is submitted, PgBouncer will now drop the user's connections as a reaction to these new values. PgBouncer will prioritize killing any idle and unused connections, and then kill the oldest active connections across all pools owned by the user to achieve the configured connection limit.

In addition, this PR also updates the SHOW USERS; command to display the maximum configured connections per user to increase visibility when throttling users.

In a production multi-tenant cluster, we have seen the need for PgBouncer to enforce maximum connections per user across all pools. When our upstream services (PG users) acquires too many connections while executing expensive and/or repetitive queries, this often puts strain on our Postgres primary server and starves CPU/Disk IO resources at the server. To remediate this, currently we manually constrain the user to maximum number of Postgres connections at server side via ALTER USER "some_bad-user" WITH CONNECTION LIMIT 123;. We've seen a clear correlation between the connection pool size (concurrency) per tenant denoted in green and database resource load denoted in yellow:

Having this option in PgBouncer would be very convenient because:

1. Postgres does not actively kill existing connections that surpass the new limit (which means load does not immediately reduce)
2. This opens the option for operators to build custom scripts that can automate per user connection throttling in PgBouncer via the SET USER ... command

Note

This PR follows from #706 and has some overlapping commits. The previous PR should merge before this one.

cc @viggy28