Perf improvement to liftover

[John-F-Wagstaff]

Is your feature request related to a problem? Please describe.
Lift over via pyliftover is currently excessively slow due to caching the gziped versions of the chain-files and having to re-uncompress the files each time they are used.

Describe the solution you'd like
If we un-gzipped the chainfiles on second use (since they download on first use) we should save time on each successive usage.

Describe alternatives you've considered
Performance testing is needed to confirm that this actually works, it might possibly be better to leave as is in some cases (depending on disk IO vs un-compression time).

[Peter-J-Freeman]

I also checked one of the servers. Unless no intergenic liftovers have been performed in several months, the files were not there, so we need to create the dir .pyliftover and give write privileges. This may be why I thought the download was manual.

@John-F-Wagstaff we confirmed the default download path is ~ right?

[John-F-Wagstaff]

No idea, but we probably don't need to worry about that. The default location for urllib.request.urlretrieve() is used, as only a url is passed. This function returns the filename used, which is then used to do a shutil.move to the intended location, if and only write_cache and (cache_dir is not None).

since we get a successful result and cache_dir defaults to os.path.expanduser("~/.pyliftover") and write_cache defaults to True, none of which we change, it should be that urllib.request.urlretrieve succeeds, but then the move fails, and we fallback to a return gzip.open() of the original tempfile (which must be working to get any kind of result). So long as the target .pyliftover directory exists and we have working permissions we should be fine. In fact you could run it locally, get the chain-files and copy them into the servers perceived ~/.pyliftover, without permissions enabled except for read, and it should also be fine too.