feat: db optimizations, backups optimizations

[yocontra]

Partial of #1126 (does not include partitioning).

Included in this PR:

• Improves the docker-compose for the database by specifying CPU and RAM constraints
• Updates the postgres dockerfile to use the latest PG (13) to match what we run in production/staging
  • Also improves it by adding additional logging, which is useful when working with the DB on local dev
• Improve the DB configuration
  • Many other settings aren't able to be configured like this (Heroku doesn't expose most flags), noted in Postgres improvements #782 so I did what I could within the constraints of what we can do inside the DB
• Improves the "backup" system - instead of having its own table with a many to one relationship, add a new key backup_urls for each upload. This removes a redundant large table (12M uploads = > 12M backup rows), and speeds up create_upload by removing more inserts.

[hugomrdias]

LGTM

[yocontra]

Migration, tested against staging already:

ALTER TABLE "upload" ADD COLUMN "backup_urls" TEXT[];

UPDATE "upload" SET "backup_urls" = (SELECT array_agg("url") FROM "backup" WHERE "upload_id" = "upload"."id");

DROP TABLE "backup";

[yocontra]

Optimized migration for production, batching updates for 64M rows into smaller queries to take less locks and prevent any downtime:

https://gist.github.com/yocontra/4ae719b42a54c4582ca28fcac74199d0

[yocontra]

@mikeal @hugomrdias This is ready to deploy - it has been run against staging and tested against a clone of the production database. Please let me know what next steps are.