Download and multiprocessing updates

[TimoRoth]

Goes back to the previous download behavior, while keeping the changed config intact.

While testing, I also found that it'd be nice to see which glacier crashed in which task while multiprocessing, so I added a wrapper-exception around it with the rgi_id and task name if those are available.

[fmaussion]

While testing, I also found that it'd be nice to see which glacier crashed in which task while multiprocessing, so I added a wrapper-exception around it with the rgi_id and task name if those are available.

Yes, there are plenty of things that would be nice to know after run. I forgot to write them down but I'm going to do new runs soon and maybe we can define a strategy for better runs.

One of the things I'd really like to have is a list of successfully applied tasks on a glacier. Then, if you want to apply the task again on the same glacier it is ignored, unless forced by the user.

[fmaussion]

I'm not sure why the test is suddenly failing, I think we can merge this

[TimoRoth]

I have one more idea for an addition, the test failure seems unrelated.

[TimoRoth]

This adds a parameter to override the cache layout, so if some data files are usually stored in a specific format, it can now be defined without having to manually intervene or copy the files around.

[fmaussion]

@TimoRoth if you have time could you look at this PR on xarray? pydata/xarray#1393

Here they implement a relatively simple checksum to make the algorithm more robust. Like Stephan I am quite surprised as to why it's not implemented in urlretrieve per default, but if it can make our downloads more robust...

[TimoRoth]

That's a special case for downloads from github, as github can give you a checksum for every file.
As most (all but one) of our downloads are not from github, we can't do something like that.