Move functions to connect to database servers to a common package

[gabrielcorado]

Part of #44956 (RFD 0181)

Context: The PostgreSQL access through WebUI requires us to establish connections to database servers from the web package (not implemented yet). This process is the same as that used by the database proxy server (ProxyServer). Instead of duplicating the logic in those two places, we're moving the common pieces into a shared package that both can use.

This PR moves some functions to generate credentials and connect to database servers and updates the ProxyServer to use them. The new package includes three functions that the proxy server and the PostgreSQL access through WebUI will use:

• GetDatabaseServers: List database servers that can handle a specific database. (previously getDatabaseServers).
• GetServerTLSConfig: Generates the tls.Config for connecting to a database server. (previously getConfigForServer).
• Connect: Connects to a database server based on the provided list. (previously Connect).

Note

Those functions have no feature/behavior changes. They were only moved to a different package. The only changes made are in their parameters and return types. Also, this PR includes additional tests specific for those functions.

[aws-amplify-us-west-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-49225.d3pp5qlev8mo18.amplifyapp.com

[Tener]

This might be a good moment to drop the shuffleFunc global var, if you feel like it.

[greedy52]

Could you share a draft of how the new lib will be used? IMHO, ProxyServer is responsible for handling the proxying, monitoring, stats reporting, etc so it might be better to implement the "new" proxying logic in ProxyServer for web server to call. But it is hard to tell without seeing the caller.

[gabrielcorado]

@espadolini Friendly ping. Thanks!

[espadolini]

Wouldn't lib/srv/db/connect or lib/srv/db/common/connect (maybe declared or just imported as dbconnect) be better? The name srvconnect doesn't really hint at it containing database access functions, and if you're going to have to read the full package path anyway, you might as well make the package name simpler.

I like how common hints at it being good to use from outside of lib/srv/db although maybe we should start putting things that shouldn't be used from outside of a package tree in internal instead (as that will actually be enforced by the linker).