Capella proposer preparation clones a beacon state

[paulhauner]

Description

In BeaconChain::prepare_beacon_proposer, we're always cloning the state in order to compute the list of withdrawals:

lighthouse/beacon_node/beacon_chain/src/beacon_chain.rs

Lines 4764 to 4773 in 9a41f65

	// We must use the advanced state because balances can change at epoch boundaries
	// and balances affect withdrawals.
	// FIXME(mark)
	// Might implement caching here in the future..
	let prepare_state = self
	.state_at_slot(prepare_slot, StateSkipConfig::WithoutStateRoots)
	.map_err(|e| {
	error!(self.log, "State advance for withdrawals failed"; "error" => ?e);
	e
	})?;

It's nice to avoid state clones since they're generally slow (10s of millis) and use a bunch of RAM (100s of MBs). I think there's at least one case were we can avoid the the state clone; when producing a block in the same epoch as its parent. Hopefully there's some more cases too.

We could also look at some sort of caching here to avoid repeat calls to the same method.

I think this behavior is OK for Sepolia, however I think we should optimise it before mainnet.

[michaelsproul]

Duplicate of #3896 which has some more info

[michaelsproul]

I'm gonna tackle this (and #3896 by implication)