The existing group selection code (ticket
submission etc.) was relevant for beacon v1
but does no longer make sense for v2. The new
group creation process does not use ticket
submission and relies on the sortition pool
group selection. This changeset is the first
step towards the support of the new group
creation flow.

# Conflicts:
#	pkg/chain/local/local.go

Contract bindings are not ready yet so, we
mitigate that problem by triggering the
DKG loop every 100th block.

submission logic

`GroupRegistrationInterface`

So far, this function was defined in the
`DistributedKeyGenerationInterface` but
looks like `GroupRegistrationInterface` is
a better place.

That logic is now obsolete because the v2
beacon group creation looks differently and
uses the result challenge and approval mechanisms.
Because of that, we remove it from the
deduplicator and leave a TODO to implement
the new logic when the full new group creation
flow will be implemented.

threshold

This way we can use values from v2, and we can
test how DKG behaves with them.

In v1, a result of a successful DKG was always a
fully-operable on-chain group whose key material
share was registered on-disk by each member.
This is no longer a case in v2 where a DKG
result is not approved immediately and is the
subject of a challenge period. Because of that,
we modify the group registry to allow storing
non-operable candidate groups first and then
register those groups as approved once on-chain
approval takes place.

Here we detach the DKG result submission logic
from the v1 contract in favor of a temporary
code that will allow to test the DKG loop.
Once the interim ends, real v2 contract binding
should be integrated here.

submission

The real group selection is not available yet
so we just return a group whose members correspond
to the operator itself. In effect, the DKG test
loop will be performed between members belonging
to the same client instance.

If we trigger DKG every 100th block, subsequent
DKG instances overlap and cause very high
CPU usage.

Random beacon DKG will still use 64 members.
We reflect that change in the temporary
hardcoded variable.

The approach used so far was problematic because
the maximum directory size is 128 characters
which doesn't leave space for the `_candidate`
suffix.

Co-authored-by: Piotr Dyraga <[email protected]>

Co-authored-by: Piotr Dyraga <[email protected]>

loop for `DkgStarted` event.

contracts