chore: support static connection info

[rhatgadkar-goog]

This is a port of GoogleCloudPlatform/alloydb-go-connector#572 for the AlloyDB Python connector. It allows connecting to a sandbox AlloyDB instance using connection info properties from a JSON file, instead of calling the AlloyDB APIs to get this information (which is done by the internal and lazy caches).

Using a static connection info currently works for the sync client (pg8000), but doesn't work for the async client (asyncpg). When using the async client, getting timeout errors here, due to ConnectionDoesNotExistError. This is fine for now, as long as we can use the Python connector (using the sync client) to connect to a sandbox AlloyDB instance.

[jackwotherspoon]

@rhatgadkar-goog With no PR description I do not yet fully see the benefit or use-case of this change...

Is it to allow to customize the certs more easily?

[enocom]

This is a peer of what we did in Go: https://github.com/GoogleCloudPlatform/alloydb-go-connector/blob/main/options.go#L218-L246

The primary use case is for development-time convenience by removing the control plane from the connection flow. I would guess there aren't many production uses for this, but it's a big convenience for development.

[rhatgadkar-goog]

This change is needed to run multiple tests that use the same proxy_server fixture. Without it, only 1 test can successfully run. The other tests fail with "Connection refused" errors.

[rhatgadkar-goog]

This change is required when implementing the change above (swapping the order of while True and with context.wrap_socket) to prevent the test from hanging

[jackwotherspoon]

I still am not sold on this approach being the best one. There are ways to load static info without changes to the public interface. I would highly suggest looking into them more instead of just doing this purely because the Go Connector did it this way.

One example being I don't think it would be much effort to make a SandBoxClient testing object similar to FakeAlloyDBClient that is wired up to always return static connection info.

alloydb-python-connector/tests/unit/mocks.py

Line 198 in 397d34f

class FakeAlloyDBClient:

This way you could write a simple private helper method _create_sandbox_connector that would look something like this:

def _create_sandbox_connector(static_info, *args, **kwargs):
    connector = Connector(*args, **kwargs)
    client = SandBoxClient(static_info)
    connector._client = client
    return connector

This lets you not mess with the public interface for something that will never be used by customers, reducing confusion in the code and making things more readable.

[rhatgadkar-goog]

I still am not sold on this approach being the best one. There are ways to load static info without changes to the public interface. I would highly suggest looking into them more instead of just doing this purely because the Go Connector did it this way.

One example being I don't think it would be much effort to make a SandBoxClient testing object similar to FakeAlloyDBClient that is wired up to always return static connection info.

alloydb-python-connector/tests/unit/mocks.py

Line 198 in 397d34f

class FakeAlloyDBClient:

This way you could write a simple private helper method _create_sandbox_connector that would look something like this:

def _create_sandbox_connector(static_info, *args, **kwargs):
    connector = Connector(*args, **kwargs)
    client = SandBoxClient(static_info)
    connector._client = client
    return connector

This lets you not mess with the public interface for something that will never be used by customers, reducing confusion in the code and making things more readable.

We discussed that for now we will keep the current approach of having the static_conn_info as an argument in the public interface. If in the future, we find that there are more dev-only parameters, we can decide to not include dev-only parameters in the public interface and use an approach similar to this.

[jackwotherspoon]

LGTM ✅