Tuf: support updating individual metadata upon addition of target file

[lukpueh]

The repository_tool and the underlying repository_lib and roledb modules seem to live on the assumption that all roles (top-level roles and delegated targets roles) are required in memory.

In large repositories, and this is the case for the implementation of PEP 458, it might not be feasible nor necessary to load and/or have the entire repository metadata in memory at all times.

To be more specific, during ongoing operations, when adding a new target file the following operations are required:

1. find and update relevant targets metadata, e.g. "bin-n" (i.e. target file hashes and size + version number + signature)
2. update snapshot (i.e. targets metadata version number + own version number + signature)
3. update timestamp (i.e. snapshot version number + own version number + signature)

The repository tool should provide API function to support above activities without requiring any other TUF metadata on disk or in memory.

[trishankatdatadog]

Hopefully, this is not too hard to do. Happy to help on weeknights and weekends.

[lukpueh]

We have to decide if we make this a stand-alone tool, or integrate it with the current repo_tool + repo_lib + roledb + keydb stack, or if we do a combination of both.

That latter seems the most feasible for PEP 485 work. I am thinking of something like a "detached head mode" (apologies for the subpar analogy), where we use some of the existing infrastructure, but don't interfere with functions like load_repository or writeall.

If we go for a stand-alone tool, we should make use of the thoughts @joshuagl, @sechkova and I have jotted down with the goal to clean up above mentioned stack: https://docs.google.com/document/d/13cY0MD3uzwFYGnj_GkPS_rwvDEzzNpDu6cteyeYP6fY

[trishankatdatadog]

@woodruffw @lukpueh @joshuagl @sechkova @MVrachev @mnm678 @SantiagoTorres

Will and I sketched what we hope is a super-simple API for a TUF repo... WDYT?

[trishankatdatadog]

I will start hacking on this

[joshuagl]

WIP in #1112

[joshuagl]

For the purposes of the PEP 458 integration this has been resolved by the merging of #1112.