Faster image load

[hackartisan]

This improves performance in 3 ways:

1. Instead of running an aws ls per each resource in the database, we run it once per "disk" in the image filenames. This lets us call it 22 times, instead of 40 thousand times.

2. We just create the CardImage objects by parsing the file name string into the correct "path" value. This way we don't need to fetch each of the 40 thousand guide card objects out of the database.

3. Uses the ruby async library to take advantage of multiple cores and use fibers for concurrent programming

This PR also changes the progress bar to a display an elapsed time, ETA, exact percent, and total.

[bess]

🎉

[hackartisan]

currently progressbar is not printing great -- there's no time info and every update is printing on a new line, which is not great but otherwise this seems to work, and successfully runs the code concurrently.

[bess]

Cool, I've never seen Async::Semaphore before. Seems super useful!

[bess]

Also, "This lets us call it 22 times, instead of 40 thousand times" is possibly the best code commit message ever. 🤣

[hackartisan]

To get this to run without can't set a guard page: Cannot allocate memory I had to set vm.max_map_count=2097152 in /etc/sysctl.conf then sudo reboot. I'm about to do that on the prod box also (done).

The boxes have been increased to have 8 cores, 64G memory. It's running at 7.6G memory use right now on staging. I think the network or postgres machine is the bottleneck at this point, because it blasts through the ones that it finds during the find or create step, and then slows down once it hits the ones it hasn't found. I think this means it will run really fast on prod, because we were so close to having loaded all the images.