[Dynamic Protocol State] Replace dynamic weight and ejection flag with 'epoch participation status'

[durkmurder]

Context

This PR is part of initiate of addressing TODOs in #4649.
Specifically it removes dynamic weight and re-introduces concept of Ejected flag. Instead of using dynamic weight and Ejected flag we introduce a enum epoch participation status which could be one of the next values: active, joining, leaving, ejected.

💡
One interesting details is how we store ActiveIdentities in EpochStateContainer, previously DynamicIdentityEntry was encoding the dynamic part of flow.Identity, specifically flow.DynamicIdentity. I have taken another approach and instead of storing flow.DynamicIdentity and flow.EpochParticipantStatus subsequently I am storing only the Ejected flag. Reasoning for that is from point of view of ActiveIdentities we only care about ejection, not about the 'joining', 'leaving', 'active' states which are derived on the epoch itself not the identity.

[codecov-commenter]

Codecov Report

Attention: 61 lines in your changes are missing coverage. Please review.

Comparison is base (3984803) 79.71% compared to head (cdfffe9) 56.06%.

Files	Patch %	Lines
model/flow/identity.go	47.22%	18 Missing and 1 partial ⚠️
utils/unittest/fixtures.go	0.00%	13 Missing ⚠️
cmd/execution_builder.go	0.00%	6 Missing ⚠️
cmd/bootstrap/utils/node_info.go	0.00%	5 Missing ⚠️
state/protocol/util.go	0.00%	4 Missing ⚠️
consensus/hotstuff/committees/leader/cluster.go	0.00%	3 Missing ⚠️
model/flow/protocol_state.go	86.95%	2 Missing and 1 partial ⚠️
cmd/bootstrap/cmd/constraints.go	33.33%	1 Missing and 1 partial ⚠️
consensus/hotstuff/committees/cluster_committee.go	80.00%	1 Missing and 1 partial ⚠️
model/bootstrap/node_info.go	66.66%	1 Missing ⚠️
... and 3 more

Additional details and impacted files

@@                         Coverage Diff                         @@
##           feature/dynamic-protocol-state    #5039       +/-   ##
===================================================================
- Coverage                           79.71%   56.06%   -23.65%     
===================================================================
  Files                                   1      955      +954     
  Lines                                  69    88552    +88483     
===================================================================
+ Hits                                   55    49650    +49595     
- Misses                                 13    35196    +35183     
- Partials                                1     3706     +3705     

Flag	Coverage Δ
unittests	56.06% <60.64%> (-23.65%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AlexHentschel]

I think we have some ambiguity currently how we handle the degenerate case of the EpochSetup event containing nodes with InitialWeight=0. I think we allow that, don't we? Previously, those nodes would be filtered out in most cases, due to the requirement to have a positive dynamic weight. But that dynamic weight was replaced by the EpochParticipationStatus. So no, EpochParticipationStatus=EpochParticipationStatusActive with InitialWeight=0 is something to consider.

We could either categorically exclude those nodes from the consensus committees. After all, their InitialWeight is fixed for the epoch and a zero-weighted node cannot contribute to protocol progress. If we included them in the committee, we would essentially add dead weight to the signatures. So conceptually, I think it would be more intuitive to not consider InitialWeight=0 nodes as part of the committee.

But that also introduces extra edge cases. All implementations need to be consistent about filtering out zero-weighted nodes. If we mess that up, we might halt the network. Therefore, I would consider it an acceptable alternative to allow zero-weighted nodes as part of the consensus committee. They would receive an index where their signature could be included in QCs and TCs, despite it being completely useless.

please see my last two comments for further details

[AlexHentschel]

This revision had a large blast radius. Very clean changes. Great work.