client/updater design: parallel downloads

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.

Leggere i punti di ingresso esistenti Updater.refresh(), Updater.get_valid_targetinfos(list) e Updater.download_targets(list), quindi esaminare il contesto dei download paralleli di pip descritto nell’issue. Definire un ambito concreto per l’API o la concorrenza, considerando completato il lavoro quando targets e i metadati bin possono essere scaricati in parallelo senza rendere non sicuro lo stato condiviso di Updater.