Fix invalid parent hash with empty root left subtree

[birarda]

Fixes a bug with parent hash generation when the left subtree of the root node is empty.

If left subtree of the root node becomes empty (for example, when first two members are removed by a third group member) the parent hash computed during TreeKEMPublicKey::update will be invalid. A subsequent welcome will also have an invalid tree, and the welcome is unprocessable.

This occurred because parent_hashes assumed that the root node was always present in the filtered direct path, and therefore used the root node as the initial parent when doing a top-down generation of parent hashes.

[bifurcation]

Thanks for finding this. Just to recap / restate the issue here:

The problem arises when the whole left subtree of the ratchet tree is empty:

      _ = G
      |
    .-+-.    
   /     \   
  _       F
 / \     / \ 
_   _   C   D

This can arise, for example, via the following sequence of events:

• A creates a group and adds B, C, D
• C removes A and B

In this case, right now, the algorithms for creating and verifying parent hashes disagree. On the creation side, the parent_hashes function assumes that the top node of the filtered direct path is the root, so the top parent-hash link it forms is from the penultimate node to the root -- not to its actual parent. When someone goes to verify this tree, they will find that the top-level node in the committer's direct path does not have a valid parent-hash link to either of its children, since the link was instead built to the root, and thus that the tree is parent-hash invalid.

In the above example tree, C.parent_hash would be the parent hash over G and the blank left subtree. It should be over F and the (one-node) subtree at D.

[bifurcation]

Couple of minor simplifications to the test case, but otherwise LGTM.

It seems like we could actually do this as a test case on TreeKEMPublicKey::update, but we can do that in a follow-on.