Hold HeadTracker lock until persisting to disk

[dapplion]

Issue Addressed

Closes #4773
Implements the fix from #5073

Proposed Changes

When persisting the head tracker in the context of the BeaconChain, hold its read lock until it has been written to disk. Otherwise there's a race condition with the pruning thread that can cause it to persist stale data.

Additional Info

Linking another line of concern for this issue, pruning routine dropping the lock before writing the serialised head_tracker data to disk.

lighthouse/beacon_node/beacon_chain/src/migrate.rs

Lines 695 to 705 in f22e5b0

	drop(head_tracker_lock);
	batch.push(StoreOp::KeyValueOp(
	persisted_head.as_kv_store_op(BEACON_CHAIN_DB_KEY),
	));
	// Persist the new finalized checkpoint as the pruning checkpoint.
	batch.push(StoreOp::KeyValueOp(
	store.pruning_checkpoint_store_op(new_finalized_checkpoint),
	));
	store.do_atomically_with_block_and_blobs_cache(batch)?;

As long as pruning does not run twice concurrently the only other possible mutation is the BeaconNode importing a block. We have observed that happening during a unwind sequence, so it's definitely possible. In that case we can end-up with a block that exists in the DB but not in the HeadTracker. This can slightly pollute the DB but not break pruning.

[michaelsproul]

There's one smol clippy failure.

Once that's fixed I think we can merge this for v4.6.0

[michaelsproul]

yesssss for dramastically