feat(dot/parachain): create skeleton for bitfield signing subsystem

[haikoschol]

Issue Summary

Create skeleton code for the implementation of the Bitfield Signing subsystem, which is described in the Host Implementers' Guide, utilizing the subsystem pattern that has been used in other Gossamer subsystems.

Implementation Details

• Create a new package called bitfieldsigning in dot/parachain/bitfield-signing
• Create a struct called BitfieldSigning and implement the Subsystem interface on it
• Create struct for overseer message DistributeBitfield

package parachaintypes

import "github.com/ChainSafe/gossamer/lib/common"

type DistributeBitfield struct {
	RelayParent common.Hash
	Bitfield    UncheckedSignedAvailabilityBitfield
}

It might make sense to duplicate the type UncheckedSignedAvailabilityBitfield as CheckedSignedAvailabilityBitfield, add a method ToChecked() on UncheckedSignedAvailabilityBitfield that performs the validation and use that type in DistributeBitfield to ensure only valid bitfields are sent to peers.

• Create empty handler for parachaintypes.ActiveLeavesUpdateSignal
• Register bitfield distribution subsystem with overseer
• Forward the above message to the bitfield signing subsystem from overseer
• Define data structures for subsystem state (see section below for details)
• Add tests (aim for at least 60% unit test coverage)

Subsystem State

The subsystem needs access to the parachain session keys for signing bitfields. The appropriate Keystore should be
passed to the subsystem constructor as a dependency to facilitate testing. Since each new active leave results in a
goroutine being spawned, the subsystem needs to maintain state to receive data from them and to cancel them when
appropriate.

package bitfieldsigning

import (
	"context"

	"github.com/ChainSafe/gossamer/lib/common"
	"github.com/ChainSafe/gossamer/lib/keystore"
)

type signingTask struct {
	ctx      context.Context
	response <-chan parachaintypes.UncheckedSignedAvailabilityBitfield
}

type BitfieldSigning struct {
	keystore keystore.Keystore
	tasks    map[common.Hash]*signingTask
}

Ideally the implementation should avoid lock contention around the keystore. Since the signing key remains the same for the duration of the signing task, the subsystem could pass in the key pair or just the private key. The implementer should double-check that this approach is thread-safe.
This is out of scope for this issue though. It should be taken into account when implementing the signing tasks as part of the parachaintypes.ActiveLeavesUpdateSignal handler.

Again, the response channel in the signing tasks should probably use a (to be created) type CheckedSignedAvailabilityBitfield.

Other information and links

Look at other skeleton PRs to get an idea of what to code and what will become and TODO and a new issue

• feat(dot/parachain): Implement candidate backing skeleton #3497
• feat(parachain): availability store skeleton #3521
• collator protocol skeleton #3512

Acceptance criteria

Acceptance criteria are listed under Implementation Details.