Limit subnet certificate delegations to depth 1

[oggy-dfin]

As discussed in various meetings, the nested certificate delegations allowed by the spec aren't used, but have complicated the reasoning about some features (see discussions around delegations in #163 for example), and stating some properties (like the new subnet read_state requests). But we don't use nested delegations in practice and we don't have any plans to use them in the future. So this PR removes them.

[krpeacock]

This speaks to a slightly broader issue with the specification, but if there are going to be different rules for a valid subnet delegation, as opposed to what is allowed in a valid delegation chain used for a client identity to make calls to the Internet Computer, we should break down those differences more clearly.

In the actual agent implementation, this change makes delegation logic more complicated, by introducing differences in validation between responses and DelegationChain identities

[oggy-dfin]

In the actual agent implementation, this change makes delegation logic more complicated, by introducing differences in validation between responses and DelegationChain identities

I don't quite understand the objection here; the validity rules for:

1. delegation chains for user authentication and for
2. delegations used in subnet responses and canister signatures

are already quite different. The encoding is different (plain CBOR vs hash trees), the rules for signatures are different (signing the representation-independent hash of a CBOR map vs signing the root has of the hash tree), and the side conditions are also different (how the delegations are signed, and how they are restricted).

Now what has changed with the new read_state requests that refer to subnets instead of canisters is that, even for verifying the responses (and canister signatures), the side conditions are now different. I agree that that can complicate the agent's code, but that change was already done in #191.

[krpeacock]

I think all I really want is a section in the specification that offers a clear disambiguation about the different "delegation" types and what they should contain. It doesn't conflict with this proposal, but came to mind while I was reading it, based on my recent project that called for a close reading of the spec