## Description 

This is the fist part that implements Garbage Collection for consensus.

Compared to Narwhal/Bullshark where the GC round was calculated and
driven by the consensus component it self, here the single threaded
nature of the system and the fact that we do have DagState - which is
shared amongst all the components - allow us to base the gc round
calculations purely on the latest committed round as derived from
DagState.

On this PR:
* `Linearizer` has been refactored to respect the `gc_round`. When
linearizer tries to commit leader `R` , it attempts to commit everything
up to the `gc_round` that has been set from leader `R-1` (as already
discussed this is the desired approach).
* `DagState` is calculating the current `gc_round` based on the latest
commit.
* `gc_depth` has been added as a protocol config variable
* Basic testing has been added to `Linearizer`

Next steps:

- [ ] BlockManager to respect the `gc_round` when accepting blocks and
trigger clean ups for new gc rounds
- [ ] Skip blocks that are received which are `<= gc_round`
- [ ] Not propose ancestors that are `<= gc_round`
- [ ] Subscriber to ask for blocks from `gc_round` when
`last_fetched_round < gc_round` for a peer to prevent us from fetching
unnecessary blocks
- [ ] Implement new timestamp approach so ancestor verification is not
needed
- [ ] Re-propose GC'ed transactions (probably not all of them)
- [ ] Harden testing for GC & edge cases

## Test plan 

CI/PT

---

## Release notes

Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.

For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.

- [ ] Protocol: 
- [ ] Nodes (Validators and Full nodes): 
- [ ] Indexer: 
- [ ] JSON-RPC: 
- [ ] GraphQL: 
- [ ] CLI: 
- [ ] Rust SDK:
- [ ] REST API: