[consensus][dag] dag integration helpers

[ibalajiarun]

Description

• Adds DagStateSyncComputer that implements StateComputer. Dag State sync will call into state sync using this struct.
• Adds a fn to PersistenceLivenessStorage trait to expose consensusDB. Dag will take in a struct that implements DAGStorage and ConsensusDB implements DAGStorage.

Test Plan

[ibalajiarun]

Current dependencies on/for this PR:

• main
  • PR [dag] split fetcher into service and helper struct #9830
    • PR [dag][bugfix] reverse nodes before adding to dag store #9831
      • PR [dag] preliminary state sync implementation #9724
        • PR [dag] broadcast CertifiedNodeMsg with LedgerInfo #9968
          • PR [dag] dag rebootstrap #9967
            • PR [consensus] introduce CommitSignerProvider trait #10006
              • PR [consensus] epoch manager refactoring; dag is coming #9994
                • PR [dag] commit signer #10040
                  • PR [dag] store parent block info in adapter #10041
                  • PR [dag] simplify DAGNetworkSender impl #10042
                  • PR [dag] async message handler support #10055
                  • PR [consensus][dag] dag integration helpers #10056 👈
                  • PR [dag] epoch manager integration; dag is here #10007
        • PR [dag] state sync good case unit test #9832

This comment was auto-generated by Graphite.

[sasha8]

There is nothing in this PR.
Why do you need to wrap ordering_state_computer?

[ibalajiarun]

There is nothing in this PR. Why do you need to wrap ordering_state_computer?

because we are connecting ordered blocks from adapter to buffer manager directly, without going via the state computer. At this point, state computer is just for state sync, so I am wrapping ordering state computer to give it some dummy block_rx and just retain the sync logic.

We might even consider removing state computer completely for dag in future.

[zekun000]

why do we need to implement the trait? can't we just expose a sync to function?

[ibalajiarun]

why do we need to implement the trait? can't we just expose a sync to function?

I kept the trait for testing. We can have a DAG specific state sync trait as well. Not sure which is better.

[github-actions]

✅ Forge suite compat success on aptos-node-v1.6.2 ==> f9790f710bd44452febcb688cd2151b7ffcb5fa9

Compatibility test results for aptos-node-v1.6.2 ==> f9790f710bd44452febcb688cd2151b7ffcb5fa9 (PR)
1. Check liveness of validators at old version: aptos-node-v1.6.2
compatibility::simple-validator-upgrade::liveness-check : committed: 2736 txn/s, latency: 6781 ms, (p50: 6600 ms, p90: 9300 ms, p99: 10400 ms), latency samples: 180620
2. Upgrading first Validator to new version: f9790f710bd44452febcb688cd2151b7ffcb5fa9
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 1749 txn/s, latency: 16008 ms, (p50: 18600 ms, p90: 21800 ms, p99: 22500 ms), latency samples: 90980
3. Upgrading rest of first batch to new version: f9790f710bd44452febcb688cd2151b7ffcb5fa9
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 1342 txn/s, submitted: 1352 txn/s, expired: 10 txn/s, latency: 15605 ms, (p50: 18400 ms, p90: 22100 ms, p99: 22700 ms), latency samples: 89933
4. upgrading second batch to new version: f9790f710bd44452febcb688cd2151b7ffcb5fa9
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 3388 txn/s, latency: 9250 ms, (p50: 10500 ms, p90: 12900 ms, p99: 13300 ms), latency samples: 135540
5. check swarm health
Compatibility test for aptos-node-v1.6.2 ==> f9790f710bd44452febcb688cd2151b7ffcb5fa9 passed
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite realistic_env_max_load success on f9790f710bd44452febcb688cd2151b7ffcb5fa9

two traffics test: inner traffic : committed: 6934 txn/s, latency: 5658 ms, (p50: 5400 ms, p90: 7200 ms, p99: 11400 ms), latency samples: 2995500
two traffics test : committed: 100 txn/s, latency: 3156 ms, (p50: 3200 ms, p90: 3700 ms, p99: 4400 ms), latency samples: 1720
Latency breakdown for phase 0: ["QsBatchToPos: max: 0.237, avg: 0.212", "QsPosToProposal: max: 0.172, avg: 0.142", "ConsensusProposalToOrdered: max: 0.564, avg: 0.540", "ConsensusOrderedToCommit: max: 0.488, avg: 0.474", "ConsensusProposalToCommit: max: 1.031, avg: 1.014"]
Max round gap was 1 [limit 4] at version 1588339. Max no progress secs was 3.92108 [limit 10] at version 1588339.
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite framework_upgrade success on aptos-node-v1.5.1 ==> f9790f710bd44452febcb688cd2151b7ffcb5fa9

Compatibility test results for aptos-node-v1.5.1 ==> f9790f710bd44452febcb688cd2151b7ffcb5fa9 (PR)
Upgrade the nodes to version: f9790f710bd44452febcb688cd2151b7ffcb5fa9
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 5022 txn/s, latency: 6377 ms, (p50: 6300 ms, p90: 9900 ms, p99: 10600 ms), latency samples: 185840
5. check swarm health
Compatibility test for aptos-node-v1.5.1 ==> f9790f710bd44452febcb688cd2151b7ffcb5fa9 passed
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking