Implement TAP 12

[mnm678]

Add tap12 to the reference implementation. This TAP allows for greater flexibility in how keyids are generated. This will require the following changes to the client:

• [x] Remove all use of keyid_hash_algorithms and instead use the keyid defined by the repository. This step is well documented in #848.
• [ ] Check that all keys applied to a signature are unique using a standardized representation (ex modulus and exponent for rsa) so that the same key with multiple keyids cannot be applied to a threshold.
• [ ] Make a local keydb for each delegating targets role so that keys can be locally scoped to their delegating instance (ie where the keys are defined in the delegating role and used in the delegated role)

The repository code should not need to change as sha256 may still be used to generate keyids.

[mnm678]

I have started on step 1 in #1014.

[lukpueh]

Two quick questions:

1. Is there a plan to completely remove keyid_hash_algorithms in the course of the TAP 12 implementation? If not, we need to create a separate issue to do so.
2. Do others think the removal of the field deserves a decision record (#1141)? #848 has become quite a focal point for related discussions (see the many mentions from other GH issues/prs). Is it worth to retain a summary of these discussions?

[mnm678]

1. Is there a plan to completely remove `keyid_hash_algorithms` in the course of the TAP 12 implementation? If not, we need to create a separate issue to do so.

Removing keyid_hash_algorithms would be part of a TAP 12 implementation, but it might be worth adding a separate issue as we decided in #1095 that most of the TAP 12 implementation should wait on the refactor work.

2. Do others think the removal of the field deserves a _decision record_ (#1141)?
   #848 has become quite a focal point for related discussions (see the many mentions from other GH issues/prs). Is it worth to retain a summary of these discussions?

As this is already discussed in a TAP, I don't know if a decision record is needed. However, I'd rather over-document than under-document, so if others disagree we can add one.

[joshuagl]

1. Is there a plan to completely remove `keyid_hash_algorithms` in the course of the TAP 12 implementation? If not, we need to create a separate issue to do so.

Removing keyid_hash_algorithms would be part of a TAP 12 implementation, but it might be worth adding a separate issue as we decided in #1095 that most of the TAP 12 implementation should wait on the refactor work.

I think it would be good to document the removal of keyid_hash_algorithms explicitly in a separate issue, it's related to TAP 12 but not blocked by it.

2. Do others think the removal of the field deserves a _decision record_ (#1141)?
   #848 has become quite a focal point for related discussions (see the many mentions from other GH issues/prs). Is it worth to retain a summary of these discussions?

As this is already discussed in a TAP, I don't know if a decision record is needed. However, I'd rather over-document than under-document, so if others disagree we can add one.

I think it could be good to add a decision record. The field is unique(?) to the reference implementation and hasn't been documented in the specification, therefore I think it a) doesn't make sense to look for documentation on this field's removal in the specification documentation (taps) and b) regardless, it should be explicitly documented in the implementation's repository.

[jku]

This does not require much, if any, work in current python-tuf: we don't assume anything about keyids currently (most importantly, there's no expectation that keys are unique globally: same name can be used in different keys in different delegating metadata). Using keyids like "keyA" or "offline root key #1" should just work.

[mnm678]

I think we can even call ngclient the reference implementation for the TAP. We haven't solved the standard representation for keys, but I think that can be safely left to the discretion of delegators (as they are already trusted to delegate to arbitrary keys).