Automatically find the remote sql-proxy-server address from the org/db/branch combination

[fatih]

Currently, if we run the sql-proxy-client on a localhost, we need to pass the remote address we want to connect. Here is an example command:

sql-proxy-client
  --token "$(cat ~/.config/planetscale/access-token)" 
  --instance "org/db/branch"
  --remote-addr ac001fde9cdb746988cf56648d20f3d0-cc3d7d661b5e5955.elb.us-east-1.amazonaws.com:3306

The user shouldn't pass the remote sql-proxy-server address. The tool should be run in this form:

sql-proxy-client 
  --token "$(cat ~/.config/planetscale/access-token)" 
  --instance "org/db/branch" 

The significant bit is, sql-proxy-client is already authenticated to our API. It should find a way to retrieve the remote address and connect to it automatically. There could be multiple ways to get this remote address:

1. The API could embed the remote address of sql-proxy-server into the cert as metadata (SAN or as a subject field). Once the sql-proxy-client receives the signed cert, it'll read the metadata and used the remote address to connect.
2. We could use the existing /organization/:org/databases/:db/branches/:branch/status endpoint to fetch the current vtgate address. We could make sure that the returned address is also compatible with sql-proxy-server (cc @enisoc)
3. We could use a new endpoint to return the sql-proxy-server's remote address.

[enisoc]

Summary from a discussion on Slack:

The current address returned in the per-branch status is not suitable for use with sql-proxy-server. When DBSS is up, we plan to replace the per-branch address with a region-wide address. When we do, that address will be compatible with sql-proxy-server since we plan to make DBSS compatible (by embedding sql-proxy-server if necessary).

For now, we can have the endpoint that returns the client certificate also return the region-wide sql-proxy-server address as an additional field in the JSON response (so we don't have to hide it in the certificate). We currently have only one region and don't yet have a data model for per-region info, so this effectively means we would hard-code the address. We don't want to hard-code the generated ELB address, however, so we plan to create a CNAME to represent the sql-proxy-server endpoint for our one staging region, aws us-east-1.

@skottler said we should put these subdomains under a domain reserved just for DB connections. He said he would provide a list of options for domains we already own. We would then create a CNAME from something like us-east-1.aws.<domain> to the ELB address for the sql-proxy-server in that region.

[fatih]

This is finished now. Both sql-proxy-client and pscale connect commands now use the remote-addr field we return from the API. Here is an example:

The address is hardcoded here: https://github.com/planetscale/api-bb/blob/main/app/services/client_certificate_issuer.rb#L11-L13