Empty subtrees are invalid

Match draft-davidben-tls-merkle-tree-certs in saying empty subtrees are
invalid. I looked briefly at whether maybe the spec was wrong, but I
think we actually want these to be invalid?

Narrowly, there's a bug in EvaluateMerkleSubtreeConsistencyProof(). If
called with n = 0, subtree = {0, 0}, the current definition will pass
the precondition checks and go on to underflow `sn = subtree.end - 1`
and `tn = n - 1`. The spec's formulation does not have this problem.

Fortunately, this bug has no practical impact because, although we
implemented the more complex routine, we really only care about
EvaluateMerkleSubtreeInclusionProof. That function's subtree.Contains
check implicitly rejects empty subtrees. Though it is less obvious than
if we had implemented EvaluateMerkleSubtreeInclusionProof directly.

More broadly, empty subtrees seem to be weird. An empty subtree can
never be used in a subtree inclusion proof. In principle, one could make
a consistency proof between an empty subtree and a big tree, but the
current recursive definition won't actually work. If the subtree is, say
[5, 5), we'll actually unzip the tree around 5, if not cause further
mishaps. That unzipping won't work for verifying the proof anyway,
because at no point will you construct the HASH("") edge case.

In reality, a subtree consistency proof for the empty subtree should
always be the empty string, and the verification procedure is "check
that the subtree was the empty hash". But then that's also strange
because now the subtree consistency proof cannot actually construct the
bigger tree. So perhaps the consistency proof is a copy of the bigger
tree hash, just for the sake of it? But all that is still just an edge
case everywhere.

For comparison, RFC 9162 and RFC 6962's consistency proof definition
requires 0 < m < n, which similarly forbids the empty tree. As far as I
can tell, the MTH({}) = HASH() base case just never comes up.

Given that, and that the tests pass just fine, it seems subtrees should
just always be non-empty.

Change-Id: Ic0d39002a41a4d98b8df5d76cdfa7376a29be4d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/85947
Commit-Queue: Nick Harper <nharper@chromium.org>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Nick Harper <nharper@chromium.org>