Tuf: Design client library

[lukpueh]

Identify what functionality from existing updater/download modules should exist in a TUF client on top of a metadata model as sketched in #1112.

Start with API functionality.

Coordinate with #1134.

[joshuagl]

Things to consider, based on learnings from a PoC integration with pip (cc @jku):

• download progress reporting #1057
• allowing a package manager to plug-in their own network/download stack
• minimal footprint (minimal dependencies and being able to be installed independently of the repository library and tools)
• supporting metadata and targets on separate hosts, and different targets on different hosts
• ability to check for existence of local configuration for a given repository #1063

TAPs to be aware of when designing:

• TAP 3: Multi-role delegations – accepted, but not in the specification because it is not implemented for the reference implementation
• TAP 4: Multiple repository consensus on entrusted targets – accepted, but not yet in the specification. Implemented in the current reference implementation

[jku]

• allowing a package manager to plug-in their own network/download stack

Filed #1142 for this

[jku]

• supporting metadata and targets on separate hosts, and different targets on different hosts

and #1143 for this

[jku]

See #1158 for "client/updater: Parallel Downloads"

[joshuagl]

We're seeing multiple areas where the current Updater interface/API is brittle or confusing (#1143, #1174, possibly others).

I had originally expected that we would try to maintain the current updater API, but we should review that and even if we do stay close to the current API plan to fix the confusing/outdated/inflexible aspects.