[Network] Number of forks and reorgs is too high

[sea212]

It seems there is a problem during the author selection, since most of the time most of the collators try to produce a block simultaneously, which leads to an unacceptable high number of forks and reorgs.

[sea212]

As it turns out the eligibleCount of the author-slot-filter pallet is set to 50. Respecting the current active collator set size, this leads to the situation that every collator tries to produce every block, which causes a high number of forks and reorgs. Setting eligibleCount to 1 will result in only one collator being eligible for producing the next block, significantly reducing the number of forks and reorgs in the network. Should a collator not produce a block within a predetermined timespan, another collator will become eligible to produce the next block. Since the eligible collator is selected randomly, the number of produced blocks should evenly distribute along every collator in the active collator set.
Governance will be used soon to determine whether the participants of the network embrace that change.

[sea212]

Reopening because the measurement reduced the forks, but didn't eliminate them completely.