add task: download_from_url() to download a URL to a file

[tomkinsc]

This adds a task to tasks_utils.wdl, download_from_url(), to download content from an individual URL to a file, via wget. This task exists as a workaround until Terra supports this functionality natively. (cromwell already does)

This has the following inputs:

• url_to_download: The URL to download; this is passed to wget (required)
• output_filename: The filename to use for the downloaded file. This is optional, though it can be helpful in the event the server does not advise on a filename to use via the 'Content-Disposition' HTTP response header. (optional)
• additional_wget_opts: Additional options passed to wget as part of the download command. (optional)
• request_method: The request method (GET, POST, etc.) passed to wget. (default: GET)
• request_max_retries: The maximum number of (additional) re-tries to attempt in the event of failed download. (optional)
• md5_hash_expected: The (binary-mode) md5 hash expected for the file to download. If provided and the value does not match the md5 hash of the downloaded file, the task will fail. mutually exclusive with md5_hash_expected_file_url (optional)
• md5_hash_expected_file_url: The url of a file containing the (binary-mode) md5 hash expected for the file to download. If provided and the value does not match the md5 hash of the downloaded file, the task will fail. mutually exclusive with md5_hash_expected (optional)
• save_response_header_to_file: If save_response_header_to_file=true, http response headers will be saved to a separate output file. Only applicable for http[s] URLs. (optional)
• disk_size: The size of the disk used for the instance downloading the file (default: 50 GB)

Note: at present, this task only downloads a single file from a single URL. This is a design decision made for a couple reasons:

1. the output file name (and any name collision thereof) is not necessarily known in advance, since the server can specify it via the Content-Disposition response header. Returning a single file takes advantage of separation of task outputs at runtime to avoid collisions
2. Parallel execution of the task in multiple jobs on multiple complete instances can—when bandwidth is limited on the requesting side—afford faster completion time
3. Parallel execution of the task in multiple jobs on multiple complete instances spreads request load across multiple originating IPs (sometimes helpful to avoid throttling)