feat: migrate compute engine postdeployment to cloud build triggers

[glasnt]

This repo is designed to be a single Terraform module that deploys a complete sample application. In this case, there are database migrations and firebase deployments that also need to happen. These have been containerised into Cloud Run jobs, but the Terraform resource for Cloud Run jobs only creates them, it doesn't execute them.

So, we have to use Terraform in unusual ways to get this execution happening.

A way we previously did this was to deploy a Compute Engine instance, with a metadata startup script that performs actions for us, ensuring this is provisioned at the end of the apply process through use of resource dependencies.

However, given the amount of regions this solution could be deployed to, there's no one-size compute engine instance that would work in all available regions. Thus we encountered issues in testing and deployments where the compute engine instance couldn't be successfully deployed.

Compute Engine isn't required in this solution, just the ability to start jobs and call APIs.

This PR implements this functionality by creating Cloud Build triggers, and using data "http" to execute them. Given we aren't connecting these triggers to a codebase, we use a placeholder pubsub topic as the event type. We don't execute the triggers with this topic, we call the triggers via the API (as you would clicking the "Run" button in the console). These triggers can perform any arbitrary tasks we want.

Terraform normally presumes that any data calls are inert and don't have side effects. In this case, any time terraform inspects the state (including on destroy), these triggers are started. Earlier iterations in #123 had failing test cases where on terraform destroy, terraform tried to delete the jobs, but since terraform also created executions of these jobs, the delete would fail, as there were active running executions. This isn't an issue when the jobs are executed within a Compute Engine metadata startup script, because this is part of a defined resource, and isn't started as part of Terraform's state inspection process.

But Terraform can't delete resources that it doesn't know about.

---

This PR replaces the Compute Engine, Sub/Network, and VPC with Cloud Build triggers, that:

• use the created placeholder image as a step in the cloud build trigger, to apply the placeholder firebase image, and
• create a cloud run job for the database setup within the trigger itself, then execute it, then perform other setup steps.

The database setup requires an authorised connection to the Cloud SQL instance, which is complicated (but possible) to do in Cloud Build, but it's simpler to perform in a Cloud Run job.

The placeholder image execution doesn't require this complexity, so instead of creating a job to run this container, it can be run directly as steps in the Cloud Build trigger itself.

The client job could also use this method, but the terraform infra tests wait for this job to execute, so to reduce complexity in having to change tests, this was retained.

The migrate job still exists, but isn't used by the deployment process. It is referenced in walkthrough tutorials, and is useful as helper functionality.

[grayside]

Working out of a new directory seems safer, nice improvement.

[grayside]

suggestion: I think it's cleaner to specify the directory in Cloud Build step than here, where setting the directory could complicate future use cases.

[glasnt]

Work consolidated into #128