Slow to start and unstable with 7000 charts in GCP

We have had quite a lot of failures recently due to chartmuseum being super slow when rebuilding the index on the fly, having to parse 7000 charts in a Google Cloud Storage bucket.

Startup time is also dramatically impacted, taking up to 5 min. I had to adjust the probes initial delay to prevent Kubernetes from loop-killing chartmuseum.

To reproduce slow start:
* Have a bucket with 7000 charts, and no `index-cache.yaml`
* Deploy chartmuseum with DEBUG=true and initial probes delay set to 400s
* Look at the logs, in particular the delay until "Starting Chart museum" appears

To reproduce long running queries ending in timeout:
* With a 7000 chart bucket, and chartmuseum running
* Manually add a chart to the bucket
* Request /index.yaml
* Chartmuseum will notice a difference between the current index.yaml and the charts present, and will re-create the file on the fly, which takes minutes.

Note that, after cleaning 5500 older charts from the repo, response and startup times improved.

Idea for a solution:
If the time spent is waiting for I/O on the bucket, using batches to retrieve files may accelerate things (https://cloud.google.com/storage/docs/json_api/v1/how-tos/batch)