Add db client connection limit

[AndrewJackson2020]

Related to #1137. This PR allows the user to configure client connection limits at the database level. This prevents issues where SQL clients all connecting to a single database consume the entire connection limit defined in max_client_conn which effectively locks all other databases from being accessed.

[AndrewJackson2020]

Found a similar issue with this PR as with #1137 wherein the increment was not done in the correct place. This should be fixed now and added an extra assert in one of the test cases.

The implementation of #1137 is a bit more complicated than this one in that databases don't get created in multiple places like users. Because of this I did not encapsulate the limit check into a function. Let me know if you want this in a function anyways for consistency sake.

[JelteF]

When using an auth_user something is still not correct here. If you try to connect using a user that does not exist the count is not decremented correctly somehow.

auth_user does work in a bit of a weird way. See start_auth_query for some details, as well as this PR where I'm trying to fix another issue that popped up due to the confusing way in which it works: #1166

[AndrewJackson2020]

I am noticing the same thing in the #1137. Specifically I'm seeing that it logs in 4 different times initially and of those 4 times 3 logins are permanently retained. Then every additional time you log in it "logs in" 2 times and of those 2 log ins one is not decremented. Definitely something weird with this implementation as is and definitely not something we can merge in as is.

$ psql  'postgresql://maxedout3@127.0.0.1:10203/pgbouncer' -c 'show users' | grep pswcheck_not_in_auth_file
 pswcheck_not_in_auth_file |         1 |           |                    0 |                   0 |                         100 |                          0

$ psql  'postgresql://pswcheck_not_in_auth_file@127.0.0.1:10203/authdb'  -c select 1;
--
(1 row)


$ psql  'postgresql://maxedout3@127.0.0.1:10203/pgbouncer' -c 'show users' | grep pswcheck_not_in_auth_file
 pswcheck_not_in_auth_file |         1 |           |                    0 |                   0 |                         100 |                          3

$ psql  'postgresql://pswcheck_not_in_auth_file@127.0.0.1:10203/authdb'  -c select 1;
--
(1 row)


$ psql  'postgresql://maxedout3@127.0.0.1:10203/pgbouncer' -c 'show users' | grep pswcheck_not_in_auth_file
 pswcheck_not_in_auth_file |         1 |           |                    0 |                   0 |                         100 |                          4
$ psql  'postgresql://pswcheck_not_in_auth_file@127.0.0.1:10203/authdb'  -c select 1;
--
(1 row)


$ psql  'postgresql://maxedout3@127.0.0.1:10203/pgbouncer' -c 'show users' | grep pswcheck_not_in_auth_file
 pswcheck_not_in_auth_file |         1 |           |                    0 |                   0 |                         100 |                          5

[AndrewJackson2020]

So super hacky solution but I was able to fix this by essentially adding an additional boolean variable to PgSocket that specifies whether or not that client has been contributed to the total count of clients. This ensures that the recursive set_pool calls only increment the count one time. Will push this in a bit, after that we can figure out if there is a better way of doing this.

[AndrewJackson2020]

@JelteF Pushed the hacky solution mentioned in the last comment. Similar solution implemented for #1137. Also expanded test coverage to admin users, stat users, and auth pass through users.

Some macOS tests are failing but I believe these are due to flaky tests similar to #1137 as the tests that are failing are different between the two test runs. Its possible that I might have made some changes that impact that global state of the test running but I don't understand why it would not impact linux but would impact macOS. Hard for me to look into this further as I don't have a dev environment set up for MacOS.

[AndrewJackson2020]

@JelteF I believe that I fixed the macOS tests by removing my usage of the run_with_config method. I think something about how this is implemented makes tests flakier on macOS but I do not have a development environment to recreate and try to fix this.

Either way please lmk what you think about this updated solution.

[JelteF]

I'm not sure what's up with this one, but every CI job seems to be failing. I seem to remember this was basically good to merge. Was there a bad merge conflict resolution or something??

[AndrewJackson2020]

Bad merge on my end, apologies for that.

[AndrewJackson2020]

Fixed the tests. The merge created some excessive line by line diffs that I can clean up as well.

[JelteF]

Another merge conflict... I guess after I merged #1193

[AndrewJackson2020]

Another merge conflict... I guess after I merged #1193

I will take care of it.

[AndrewJackson2020]

Another merge conflict... I guess after I merged #1193

@JelteF Fixed the merge conflict. I think that the currently failing test is a flaky test.

[AndrewJackson2020]

Again, looks like the failure is a flaky test. I've noticed this seems to happen more on windows than other platforms.