feat: skew leader clock in poh-recorder

[ksn6]

Problem and Summary of Changes

The leader shouldn't populate the block footer clock with just the raw clock value.

Rather, the leader should populate the clock with bounds, as specified in solana-foundation/solana-improvement-documents#363.

[AshwinSekar]

this value also needs to go into the clock sysvar right? seems we should do it in bank.freeze

[ksn6]

this should already happen, no?

• when the leader sends out the footer, broadcast populates blockstore

• and then on the leader's replay, block component processor runs

• once feat: update clock sysvar in BlockComponentProcessor #595 lands, the clock sysvar gets populated

[AshwinSekar]

2 things:

We only send out the footer once the bank is frozen. Once a bank is frozen no more account updates should be made (the state of the bank is "frozen").

There is no "leader replay", replay just checks to see if the bank is full and calls freeze. The blockstore processor call line is only used for non leader banks

alpenglow/core/src/replay_stage.rs

Lines 3464 to 3466 in 4bfe9ed

	if bank.collector_id() != my_pubkey {
	let mut replay_blockstore_time = Measure::start("replay_blockstore_into_bank");
	let blockstore_result = Self::replay_blockstore_into_bank(

For leader banks transactions are recorded into the bank directly by banking stage

alpenglow/core/src/banking_stage/consumer.rs

Line 174 in 4bfe9ed

fn process_and_record_transactions_with_pre_results(

And ticks are registered directly via poh recorder.

This is why a bank can become frozen before it has been done shredding

[AshwinSekar]

So i think when we freeze our bank we should create and update the clock, as well as apply the state changes associated with the rewards.
Then when we're producing our footer we can grab these details for shredding.

Basically need to ensure that the leader and replayer will end up with the same bank hash in the end.