Refactor client trust/trust root management

[woodruffw]

This rips out a lot of our dedicated state, replacing it with a smaller adapter over the now-standard ClientTrustConfig message.

TODO:

• Unit tests
• Documentation (incl. README)

Closes #324.

Closes #916.

[woodruffw]

This should be good to go -- the diff is huge because of the checked-in JSON assets, but the core change is pretty minimal:

• TrustedRoot is no longer a subclass of the proto TrustedRoot, but its own class with a pImpl-style pattern for the inner proto.
• We now pass KeyringPurpose on individual APIs on TrustedRoot, rather than initializing the root with a purpose. This is more consistent with how the APIs are actually used, and makes the wrapper class a little simpler (plus, it allows for a future refactor where we only initialize the trust root once at client start, not separately for signing/verification).
• ClientTrustConfig now exists and is plumbed through via --trust-config. It's also documented in the README.

[javanlacerda]

Great update! LGTM

[jku]

On a first pass this looks great (will have another look after more coffee).

The various construction methods (production() etc) still use a lot of hard coded values and that makes e.g. SigningContext construction seem wildly different in the different cases... but as long as the client config is not yet available via TUF, some of those values are required. So I agree it makes sense to simplify that later rather than try to do some of it now

[jku]

Looks good.

There seems to be a clear path to integrating the ClientTrustConfig from tuf once that's available. I believe that will further simplify the construction options of SigningContext and Verifier (as you said the trust/config initialization can then be done once in a single place).

[jku]

I've never seen @api private and can't find any docs (maye because "api" is one of those ruined search words). What does this do?

[woodruffw]

This is a pdoc (our document generator) thing -- it marks an otherwise public API (like the ctor) as not receiving public documentation, so that we don't commit to 3p proto types in our public APIs 🙂

(Then again, it's entirely redundant here since _internal.trust is already undocumented as a completely private API.)

[jku]

This should not be private?

(same comment for verifier.py)

[woodruffw]

I think we want to eventually make it public, but doing so right now will result in a visibility mismatch: the ClientTrustConfig type is in the _internal namespace, so a public API here will need to know how to instantiate a private type.

(My thinking was that it could be left as private for 3.0, and made public with a refactor in 3.1.)