If postgres DB supports enough connections for every process (executor, uvicorn worker, main loop), use a persistent connection instead of NullPool (which does connection setup/teardown for every DB op) to save on connection setup/teardown time.

We have been using NullPools to save on total # of connections at any given time because we didn't have visibility on the number of connections a PSQL instance supports. Now that we are able to get this number, we're able to make smart choices in the trade-offs to make.

Testing:

Running sky status on a remote API server on GKE with GCP cloud SQL backend, using IAM auth.

Initial few runs of sky status are discarded to fully load modules and initialize the db connections.

this PR
2.921
2.810
2.874
2.970
2.850
avg: 2.885

master
5.515
5.492
6.008
5.590
6.111
avg: 5.7432

This PR is approx. 2X faster.

Tested (run the relevant ones):

• Code formatting: install pre-commit (auto-check on commit) or bash format.sh
• Any manual or new tests for this PR (please specify below)
• All smoke tests: /smoke-test (CI) or pytest tests/test_smoke.py (local)
• Relevant individual tests: /smoke-test -k test_name (CI) or pytest tests/test_smoke.py::test_name (local)
• Backward compatibility: /quicktest-core (CI) or pytest tests/smoke_tests/test_backward_compat.py (local)