This is a big architectural refactor which will obviate the need for hdb_* schemas and tables. Instead, hasura can start from just the metadata.yaml file which can be given as a server-flag.

Why do we need hdb_* schemas in the first place?

1. Insert permissions are based on postgres triggers on hdb_views : How can we move the logic to the app layer? Solved via #3598
2. We store lot of user generated events for event-triggers and actions in hdb_catalog : This can probably be solved by asking for user-defined tables. This also makes sense as these are user-events and not hasura configuration.
3. Easier dev workflow: Currently, having hdb_* is easier because you don't need to continuously reload the metadata file or even generate one (e.g. how will people try-out on heroku?).

If we do this, we can solve the following use-cases quite trivially:

1. Hasura(s) on multi-tenant postgres
2. Handle lot of existing postgres users, who don't have admin access on postgres.
3. Co-existing versions / Blue Green deployments of Hasura
4. Configuration option to rename the metadata catalogue schema #3496

But this would create new problems like:

1. What if users modify metadata on prod? How will they persist new metadata? How will they sync across instances?
2. Event logs are in public namespaces now. What if we need to do migrations on event log tables, etc?