[infrastructure] add explicit autoscaling logic to Hasura service

[freemvmt]

Relates to this ticket.

This PR follows hot on the heels of #4080 and #4081, neither of which resolved the issue with Hasura (although I think the latter was necessary because the number of connections the AWS RDS database could handle was a limiting factor).

It implements the following:

• health checks for both the hasura and hasuraProxy containers, with values based on the docker setup
• new env variables to give a long timeout for a new Hasura server to load metadata and run migrations at boot, ensure said migrations run sequentially (not concurrently) to minimise chance of overloading CPU, and show debug level logs to easily diagnose whatever's going on
• according grace periods / timeouts throughout
• doubles CPU only (to 1GiB) for the hasura container (changed in staging and prod yaml for consistency)
• explicit scaling policies for the Hasura ECS service, which should trigger a scale out when CPU usage is over 60%, or memory usage over 75%

Those last values are up for grabs/can be adjusted over time. Based on a load test I just ran (with 1000 users hitting the Hasura graphQL endpoint every few seconds), it's CPU utilisation that I would expect to be the trigger.

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

Thanks for comments throughout here & really getting to grips with all this Pulumi config ! Happy for this to be tested on staging whenever you're ready 🏁

[freemvmt]

See #4103 for minor fix to this PR.