DPLT-1049 Provision separate DB per user

[morgsmccauley]

This PR updates the Lambda Runner provisioning step to create a separate Postgres database per user. This provides greater security, preventing users from manipulating other users data within the provided SQL.

I've added the high level steps, as well as some notes on the changes to them, below:

1. Create database/user in Postgres

It's possible to run SQL against Postgres via Hasura, but the provided statements are run within a transaction block. As CREATE DATABASE can not be run within a transaction, we need a direct connection to Postgres to create new databases.

Crypto random passwords are generated for each PG user, these will be stored by Hasura in plain text within its metadata table. Exposing the password/connection string via an environment variable isn't really feasible as this would require: creating a secret, updating the Cloud Run revision, and restarting the instance. We can look at more secure options for this in future.

2. Add database to Hasura

Database connections are added as 'data sources' to Hasura, this makes up the majority of changes to Hasura Client - making source configurable. As mentioned above, these connections are stored in the Hasura metadata tables and are therefore persisted across restarts.

A database will be created per account, we must therefore check if the datasource exists before provisioning to avoid attempting to recreate it when the account creates their second indexer.

3. Run user provided SQL

There are two potential conflicts when provisioning an endpoint:

1. Postgres - a user could theoretically create two different functions with the same tables, to avoid conflicting table names a new schema is created per function. Since this is scoped within the accounts DB, we can name this after just the function, rather than a concatenation of both account/function like we have currently.
2. GraphQL - Hasura exposes all tables from all databases, with the above, we could end up with conflicts when two different accounts create the same named function and table(s). To avoid this conflict each database has it's own namespace, which scopes all top-level fields to that namespace.

The end result is a query like to the following:

query {
  account_name {
    function_name_table_name {
      column
    }
  }
}

Instead of namespaces, we could create a DB schema named after both account ID/function, which would result in the top-level fields we have currently, i.e. account_name_function_name_table_name. But I believe the namespace reduces the noise and makes GraphQL operations more readable.

4. Track tables, foreign key relationships, and add permissions

These steps are mostly unchanged, but have been slightly refactored to take in to account execution against different databases/sources.

Other Considerations

By default, all users are able to connect to the template databases, which are used as 'templates' for new databases. To prevent users from modifying these templates we should remove PUBLIC access from them:

REVOKE CONNECT ON DATABASE template0 FROM PUBLIC
REVOKE CONNECT ON DATABASE template1 FROM PUBLIC