dev: improve flow to add block header in database (for tests)

[tcoratger]

Describe the enhancement request

Currently in the codebase, for our tests, there are a few places where we have to manually add a block header in the database:

kakarot-rpc/src/test_utils/katana/mod.rs

Lines 300 to 328 in c5a2667

	// We use the unpadded block number to filter the transactions in the database and
	// the padded block number to update the block number in the database.
	let unpadded_block_number = format_hex(block_number, 0);
	let padded_block_number = format_hex(block_number, U64_HEX_STRING_LEN);
	// The transactions get added in the database with the unpadded block number (due to U256 serialization using `human_readable`).
	// We need to update the block number to the padded version.
	tx_collection
	.update_many(
	doc! {"tx.blockNumber": &unpadded_block_number},
	UpdateModifications::Document(doc! {"$set": {"tx.blockNumber": &padded_block_number}}),
	)
	.with_options(UpdateOptions::builder().upsert(true).build())
	.await
	.expect("Failed to update block number");
	// Same issue as the transactions, we need to update the block number to the padded version once added
	// to the database.
	let header_collection = database.collection::<StoredHeader>();
	let filter = EthDatabaseFilterBuilder::<filter::Header>::default().with_block_number(block_number).build();
	database.update_one(StoredHeader { header }, filter, true).await.expect("Failed to update header in database");
	header_collection
	.update_one(
	doc! {"header.number": unpadded_block_number},
	UpdateModifications::Document(doc! {"$set": {"header.number": padded_block_number}}),
	)
	.with_options(UpdateOptions::builder().upsert(true).build())
	.await
	.expect("Failed to update block number");

or as described here #1485 (comment)

The process is very manual, tedious and not clean. We should find a way to implement this cleanly under a feature flag testing for example in the database implementation in order to reduce to a single line of code the insertion of block headers in the database.

As it is only for testing purposes, we should take care and only implement this under testing feature flag or in appropriate testing file so that it is not in the production binary.

Ref #1485 (comment)