client refactor: consider API changes

We should consider if we want to additions/changes to the API – this would be a good time for them.

Possibilities:

1. Namespace shortening: currently using the client looks like this:

from tuf.client import updater
updater = updater.Updater() # that looks stupid and is a name clash

This is a small thing maybe but having both client and updater module does not seem useful: I think we could just as well have

from tuf import client
updater = client.Updater()

This should be possible by having a client/__init__.py that exports Updater (and FetcherInterface).

2. Mirrors: this is arguably the most complex part of the client API, probably mostly unused and is kind of hidden: I wonder if we can/should make it better? pip does need the mirrors config but even that use is not what mirrors config was designed for: pip potentially changes the config before every single new target download, switching the mirror list based on whether it’s downloading index files or distribution files… #1307, #1143

3. the actual updater API do we want to improve the get_one_valid_targetinfo + updated_targets + download_target call sequence in any way? * Possibly provide a helper that does the obvious thing (given a target name, just make sure it is downloaded) * should the actual local paths be returned? It feels odd that client has to build the paths when updater already had them

[joshuagl]

1. I’m 💯 for the namespace shortening.
2. I do want us to think about the mirrors, it’s a popular topic #1307 and #1143.
3. I like both of these suggestions, we also have https://github.com/theupdateframework/tuf/issues/1135 has some additional thoughts on client API

[jku]

I’m closing as individual ideas here now have issues of their own