Stabilize disk and memory utilization

[brycekbargar]

For every endpoint except for instances LDLite had been running great. This is a result of a weeks long struggle to get the instances to also run. There were two big issues

• Starting a transaction and then having a bunch of intermediate temp tables ballooned the disk space as the rows were never cleaned up even though they were deleted
• Depending on the query plan the memory would sometimes spike to 100% and DigitalOcean would kill the connection

My initial theory was that this was disk spilling and so I reviewed a lot of query plans to eliminate it. Each query was a little guilty but switching to WITH ORDINAL instead of ROW_NUMBER and switching away from multiple exists queries based on a single CTE cleaned it up. The memory spikes were due to the query plan going bad because it couldn't see into the jfuncs. I ended up using the postgres native name so the query planner can be happier and just shimming them for duckdb. Rather than wait until the end of the transaction to drop all the temp tables they're now session scoped and get dropped explicitly after they're no longer necessary.

This PR loads all the data and does it in a single night which is a huge improvement over not running or taking 34 hours. As I worked through it I discovered bigger changes that could tame the memory and disk but was hesitant to rewrite a large chunk before I had something that worked "ok". The disk and memory still balloon too much for a release of LDLite but they at least work in Five Colleges environment with excessively provisioned disk.