The best place to catch share problems is immediately during parsing from
`&str`, however, because `validate_shares` takes any type that implements the
`IsShare` trait, and there's nothing about that trait that guarantees that the
share id, threshold, and secret length will be valid, I thought it best to leave
those three tests in `validate_shares` as a defensive coding practice.
I think that using hashmaps and hash sets was overkill and made the code much
longer and complicated than it needed to be.
The new code also produces more useful error messages that will hopefully help
users identify which share(s) are causing the inconsistency.
It's possible that two different points have the same data.
To give a concrete example consider the secret polynomial `x^2 + x + s`, where
`s` is the secret byte. Plugging in 214 and 215 (both elements of the cyclic
subgroup of order 2) for `x` will give the same result, `1 + s`.
More broadly, for any polynomial `b*x^t + b*x^(t-1) + ... + x + s`, where `t` is
the order of at least one subgroup of GF(256), for all subgroups of order `t`,
all elements of that subgroup, when chosen for `x`, will produce the same
result.
There are certainly other types of polynomials that have "share collisions."
This type was just easy to find because it exploits the nature of finite fields.
