Flatten TrieUpdates before persisting

[mediocregopher]

Describe the feature

When persisting trie updates we do so block-by-block:

reth/crates/storage/provider/src/providers/database/provider.rs

Lines 355 to 370 in b79c58d

	for block in blocks {
	let trie_data = block.trie_data();
	let ExecutedBlock { recovered_block, execution_output, .. } = block;
	let block_number = recovered_block.number();
	self.insert_block(&recovered_block)?;
	// Write state and changesets to the database.
	// Must be written after blocks because of the receipt lookup.
	self.write_state(&execution_output, OriginalValuesKnown::No)?;
	// insert hashes and intermediate merkle nodes
	self.write_hashed_state(&trie_data.hashed_state)?;
	self.write_trie_changesets(block_number, &trie_data.trie_updates, None)?;
	self.write_trie_updates_sorted(&trie_data.trie_updates)?;
	}

We could instead accumulate all trie updates into a single TrieUpdatesSorted, and persist that in a single write_trie_updates_sorted call after looping over the blocks.

NOTE: some care needs to be taken with trie changesets. We still must persist changesets for every block in the loop, but we need to provide the write_trie_changesets with the accumulated trie updates as an overlay so that it sees the correct state for the block.

NOTE(2): It might be possible to use the ComputedTrieData's anchored_trie_input here, assuming that the anchor block matches the db's tip when save_blocks was called.

Additional context

No response

[cwkang1998]

Would like to take this if this is not already being worked on