New API: Revise "update" methods in tuf/api/metadata.py

Description of issue or feature request: Currently, we are using a method called update to update certain fields of the metadata represented by our classes. In Timestamp we are updating the information about the meta part from signed or more precisely the information about snapshot.json In Snapshot we are updating the information about target.json or a specific delegation which are again in meta part from signed portion of the metadata file. In Targets we are updating information about a specific target which is in targets part from signed portion of the metadata file.

It’s clear that by update the different classes are doing different stuff and it’s a little ambiguous. One could easily ask the following questions: In Snapshot with update do we update one or all files from meta? In Targets with update do we update the information about one or many target files? In Timestamp with update what are we updating? The spec version, the expiry date?

@lukpueh gave more insight with the following comment:

I would say the name "update" in {Targets, Snapshot, Timestamp}.update(...) does not stand for 
"update attributes of an object" but rather for "update attributes of an object in the course 
of a repository update". 
I am talking about the Update in The Update Framework.

Right now a TUF integrator needs to call exactly these update methods explicitly 
whenever target files are added, thus the above meaning of update made sense to me.

here: https://github.com/theupdateframework/tuf/pull/1223#discussion_r532665409

We need to revise the need for the update functions, their naming, and purpose.

Important Consideration We know that Warehouse is using our current version of tuf/api/metadata which means they are using the update methods. Resolving this issue will be a breaking change and we should be careful when to do it.

Solution Revise the need of the update functions as a whole. Maybe we can replace them with add/remove functions?

[jku]

in the future we will add a controller class which will handle the update.

Following is my gut feeling on this, not going to fight on these: I think it makes sense to keep the metadata API unaware of the complexities of the client update process (and just include things that are truly common to all of the tools that need to handle metadata) – but do agree that a client metadata controller is required somewhere: I estimate that that component will include most of the tricky bits of the updater code so I’d be inclined to make it an implementation detail of the updater (instead of part of the public API) at least in the beginning

[lukpueh]

Closing in favor of #1627