Add timeout + error handling to dbt deps requests to hub site

[drewbanin]

Describe the bug

We've seen a couple of reports of dbt hanging when connecting to the hub site (note the timestamps):

2020-03-10 00:07:57,503415 (MainThread): Response from registry: GET https://hub.getdbt.com/api/v1/fishtown-analytics/dbt_utils/0.2.5.json 200
2020-03-10 00:07:57,507527 (MainThread): Making package registry request: GET https://hub.getdbt.com/api/v1/fishtown-analytics/dbt_utils.json
2020-03-10 16:50:30,597385 (MainThread): Flushing usage events
2020-03-10 16:50:30,602693 (MainThread):

The dbt process was, somehow, alive for these 16+ hours and the process needed to be terminated manually to get it to exit. Let's:

• figure out how something like this could happen (did the request really stay open for 16 hours??)
• see if there's any additional error handling we need to add here
• add a timeout to these hubsite requests to cancel them after some timeout. I think 30 seconds is reasonable.
• It would be good if dbt retried fetching packages a couple of times if an unhandled (ie. not 404) error occurs

Steps To Reproduce

This one is super tough to reproduce. No reliable repro case at the moment.

The output of dbt --version:
This was most recently replicated on dbt v0.15.0

The operating system you're using:
This was replicated in dbt Cloud

The output of python --version:
This was replicated in dbt Cloud

[jrandrews]

What happens if you literally unplug the network cable (or turn off the wifi) in the middle of dbt running?

[drewbanin]

@jrandrews it depends on what you run!

I'm seeing:

$ dbt deps
Running with dbt=0.16.0-rc2
Encountered an error:
Unable to connect to registry hub

For a dbt run, I see that the database query times out after a couple of retries on Snowflake, with similar behavior expected on other databases.

I think the bigger failure mode here is when the remote keeps the connection open but never returns any data. A timeout on these requests would help there.