client/updater design: parallel downloads

[jku]

Updater should in some way support parallel downloads.

This came up because I found an obscure corner in pip that does index file downloads in parallel in pip (pip list --outdated): if I plug my TUF-support in there, TUF Updater gets called from multiple threads and very bad things happen.

Some notes on this:

• for the pip use case, letting pip handle the actual downloads would remove 50% of the need for this -- but bin metadata downloads would still be sequential (and Updater.refresh() would still be thread-unsafe)
• Still, parallel downloads (for both targets and bin metadata) is probably a wanted feature in other user-facing apps as well: it is faster and is something package managers already often do
• this feature does not mean that TUF API absolutely needs to be threadsafe: many use cases would be covered by small API change: Updater.get_valid_targetinfos(list) and Updater.download_targets(list) could still be a single-threaded API but they could be implemented in a way that uses multiple threads and multiple connections to the server. I have no idea how easy this would be though.
• The nicest solution might be a low-level Sans-IO style API (a state machine with events) or at least something that is asynchronous to the users. This API is then wrapped by a simple I/O layer that could look much like it now does. This would mean a large change.

[jku]

Issue #1213 updater: abstract out the network IO might provide a reasonable path to parallelized target downloads: Updater would not need multi-threaded code or to even be thread-safe: custom Fetchers could implement the parallelization and the Updater API just needs to handle a list of targets to update instead of a single target.