feat(consensus): dag state to evict blocks based on gc round

[VorobyevIlya]

Porting upstream change: MystenLabs/sui@34416bf

Description of change

Currently we evict the cached ref entries in DagState whenever we
flush. At this point we evict the entries for each authority by
dropping all the blocks which are <= evict_round, where evict_round = authority_latest_commit_round - CACHED_ROUNDS . The CACHED_ROUNDS
here allow us to keep around for a little longer committed blocks. Of
course all the blocks that are > evict_round are kept.

This can work fine so far where we don't use GC , as we expect
eventually to include blocks from other peers as weak links - no matter
how far back they are - and that will move the
authority_latest_commit_round and trigger the eviction of their blocks
from our memory. Now with GC we don't have those guarantees. It is
possible to get to a scenario where even a group of slow nodes that are
constantly behind gc_round, they keep proposing but their blocks never
get committed. Although their blocks should not end up in others DAGs ,
they will remain in their own and fill up their memory. Overall, the
current approach will provide weaker guarantees.

This PR is changing the eviction strategy so it's driven by the
gc_round. Doing though the eviction purely on the gc_round will
change a lot the semantics of the DagState as one of the intentions
was to keep recent cached data from each authority. That would also be
particularly visible for authorities for which we do not have frequent
block proposals, as we could end up always evicting all their blocks if
they are behind the gc_round. Then this would not allow us to do
certain operations we used to do before with cached data(ex get latest
cached block per authority).

For that reason this PR is changing a bit the semantics of the
CACHED_ROUNDS and from now on it will be the minimum/desired amount of
rounds we want to keep in cache for each of authority. The eviction
algorithm will still attempt to clean up records that are <= gc_round,
but it will also make sure that CACHED_ROUNDS worth of data are kept
around.
Especially for more edge case situation where a node has not produced
blocks > gc_round, we guarantee to keep CACHED_ROUNDS even when all
of them are <= gc_round, but we'll eventually evict anything before -
practically like a moving window.

Links to any relevant issues

Fixes #5643

Type of change

Choose a type of change, and delete any options that are not relevant.

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How the change has been tested

Describe the tests that you ran to verify your changes.

Make sure to provide instructions for the maintainer as well as any relevant configurations.

Change checklist

Tick the boxes that are relevant to your changes, and delete any items that are not.

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have checked that new and existing unit tests pass locally with my changes

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

4 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
apps-backend	⬜️ Ignored (Inspect)	Visit Preview		Feb 27, 2025 8:34pm
apps-ui-kit	⬜️ Ignored (Inspect)	Visit Preview		Feb 27, 2025 8:34pm
rebased-explorer	⬜️ Ignored (Inspect)	Visit Preview		Feb 27, 2025 8:34pm
wallet-dashboard	⬜️ Ignored (Inspect)	Visit Preview		Feb 27, 2025 8:34pm