feat(dot/parachain/bitfield-signing): handle ActiveLeavesUpdateSignal message

[haikoschol]

Issue summary

The bitfield signing subsystem only handles parachaintypes.ActiveLeavesUpdateSignal messages from the overseer. This message usually triggers creation of one or more bitfield signing tasks. The output of these tasks is sent to the bitfield distribution subystem. Only validators create and sign bitfields.

The creation of the bitfield itself is out of scope for this issue. It should be mocked here and implemented as part of #4414.

Implementation details

For all leaves that have been deactivated, cancel the signing tasks associated with them.

For all activated leaves, spawn a new signing task. The task needs to perform the following steps:

1. Wait a while to let the availability store get populated with information about erasure chunks.

In the Parity node, this delay is currently set to 1500ms. It must be possible to abort a signing task while it is waiting. Ideally this should be covered by a test.

2. Create the bitfield.

This part is out of scope for this issue. The input to the process is a context for cancellation, a relay parent hash, the validator index of the node and a channel on which to send the result. Just create a function or method constructAvailabilityBitfield that returns a hard-coded bitfield, or whatever makes sense for testing purposes. Roughly:

package bitfieldsigning

import (
    "context"

    "github.com/ChainSafe/gossamer/lib/common"
    parachaintypes "github.com/ChainSafe/gossamer/dot/parachain/types"
)

// this could also just be parachaintypes.BitVec
type availabilityBitfield []bool

func constructAvailabilityBitfield(
    ctx context.Context,
    relayParent common.Hash,
    validatorIdx parachaintypes.ValidatorIndex,
    response chan<- availabilityBitfield,
) {
    response <- availabilityBitfield{ ... }
}

3. Sign the bitfield with the validators parachain session key.

4. Send a DistributeBitfield message containing the created bitfield to the overseer.

Depending on the order of implementation, the struct for this message should have been defined as part of either #4232 or #4413.

Other information and links

• Parity node implementation
• parachaintypes.BitVec

Acceptance criteria

• New code is 60% covered with unit tests