Performance/build timeout

These are _kinda_ in order, but not necessarily.

1. implement PG Bouncer for connection pooling/management
* http://www.pgbouncer.org/features.html
* this would give us more control over queuing and how we handle open connections
1. async wokers on gunicorn
* this would allow those requests to be concurrent on joplin, but
* during site builds, joplin seems to spend more time with requests waiting in a queue than anything else. this is probably because the site build process files off a bunch of requests at once, and gunicorn is handling them appropriately for how we have it set up but not really appropriate for the kind of app we've actually built. The short answer is that is what the above PG Bouncer is for
* switching to this kind of setup was pretty easy (I have a PR out: https://github.com/cityofaustin/joplin/pull/526), but a naive implementation leads to lots of DB connections being created for every request
1. try a switch from gunicorn to uswgi
* research seems kinda conflicting, but it seems uswgi is more robust and may deal with our variable load better. it also seems easier to configure by environment which might be nice.
1. note pros and cons of vanilla gunicorn vs async gunicorn vs uswgi, make a decision ( for instance, if we stick with gunicorn it is designed to be run with a proxy buffer so we ought to implement that (there may be a heroku buildpack that saves some time with that))

1. upgrade PG in heroku to something being the free tier
* this would allow more connections, and allow the PG database to have its own cache, which should greatly help response time of multiple requests
1. Optimize our api queries to reduce the overall number or requests and improve response time
* we should do this regardless of the above steps, but it will be more time intensive
* note the outline on generally how querysets affect performance, links to relevant libraries:
https://github.com/cityofaustin/techstack/issues/3596