Cohort parametrization safety features

[arjunhassard]

I originally envisaged these to be v7.x features - i.e. not needed for the MVP launch - but we may need to bring them forward due to direct requests from early adopters (see RFC comments).

(1) On a per-adopter basis, the cohort authority needs to be able to permanently relinquish their power to modify the cohort. In some cases this can happen at initialization, but it would be more useful if this 'abdication' could occur later, as and when an adopter's business case demands it. In other words, some applications will require initial tweaking of the cohort size/composition/etc to fit budgets and behavior, but at some point the power to continue tweaking should be discontinued.

Note that this doesn't imply the cohort itself is immutable – obviously it will still need rules in place for operator replacement (either due to deauthorizing stakers or based on some app logic) – rather, that those rules for operator replacement are now immutable.

This functionally could be looped into the broader requirement to transfer cohort authority (e.g. to a DAO), which could be facilitated by a special-purpose NFT (@jMyles) – here, the NFT could be sent to a burn address.

(2) More universally, we will eventually need safety features that prevents a cohort authority from rug-pulling their users and discontinuing the cohort. Similar to sponsor trust reduction (i.e. that there's always a 5-6 month minimum warning if payments stops), we could design an in-built time delay for drastic changes to the cohort. Here are some draft examples:
(a) Add more nodes to cohort – no time delay
(b) Remove one node – 1 week delay
(c) Remove up to 1/3 of the cohort – 1 month delay
(d) Remove between 1/3 and 2/3 of the cohort – 3 month delay
(e) Increase minimum stake for new nodes replacing old nodes – no time delay
etc.

Related to nucypher/taco-web#168