Moving height, round,solutions, and transactions to bft for clients

[miazn]

Motivation

Right now, we only track height, round, solutions and transactions in consensus, and not in the node/bft CoreLedgerService, therefore we cannot track what height clients are at. This PR moves those metrics into the CoreLedgerService.

Also removed the numTransmissions metric, as you can just sum the numTransactions and numSolutions in the end analytics service (metrics/prometheus or visualization/Grafana) if needed.

Test Plan

These graphs show where I add 5 clients to the network.

[howardwu]

How does this track syncing vs advancing? I think this now muddies the two up.

[miazn]

Before it would not track block height if not participating in consensus, so clients would not show any metrics. Now, if a client is syncing it will show what block height it is synced at for that timestamp-- if the height is below the max height then it's syncing, I believe.

[howardwu]

How does this help Grafana delineate what is syncing vs advancing?

[howardwu]

Why would a client sync a block below its current max height?

[miazn]

Sorry, that was badly worded-- here is a better graph of a devnet w 4 validators that runs for 30 mins, then i add 5 clients to sync up w the network-- the green line is block advancement of the validators, and then the lines that start at 12:00 are the clients joining the network, you can see the rate of advancement as it syncs to the current network block height. Since the CoreLedgerService:advance_to_next_round function is used both in sync and regular consensus advancement, we capture the state of both validators participating in consensus and clients syncing with the network