Validate 'small count cohort' DKG for memory optimization about ferveo HOT 2 CLOSED

One downside of limiting the cohort size – it reduces the scope for a redunancy-driven mitigation of cohort deterioration. If
(a) proactive secret sharing / public key persistence proves impossible
and/or
(b) we find a workable compromise with long cohort persistence through long winddowns or incentivized long-term staker commitment and proactive user-driven public key replacement

then we may have prematurely limited the scope for large cohorts to provide longer, more robust redundancy and cohort deterioration resistance

Note this also brings into question the brittleness of a fixed 2/3 m-of-n ratio – even if adopters don't wish to tune it, we may want to select an m-of-n ratio more optimized for redundancy – e.g. 50% threshold (20-of-40, 50-of-100 etc)

See #78

@cygnusv

from ferveo.

The final checkbox – 'Raise constraint of 8, 16, 32 and 64 DKG group size with adopters' – has already been partially explored (and confirmed as viable) with adopters, and is now subsumed by the research into the practicality (from a collusion-resistance, redundancy, latency & cost perspective) and corresponding validation required to complete nucypher/taco-web#168

from ferveo.