[Provider] Improve the `L1MessageProvider` interface and implementations

[greged93]

The L1MessageProvider uses a cursor pattern which is a impractical and can lead to misses in cases where we forgot to update the cursor. Instead of a cursor, we could just return an iterator over the messages, which we could easily get from the database by adding a method similar to get_l1_messages which would take an index or a queue hash.

rollup-node/crates/database/db/src/operations.rs

Lines 172 to 181 in db1faaa

	/// Gets an iterator over all [`L1MessageEnvelope`]s in the database.
	async fn get_l1_messages<'a>(
	&'a self,
	) -> Result<impl Stream<Item = Result<L1MessageEnvelope, DatabaseError>> + 'a, DatabaseError>
	{
	Ok(models::l1_message::Entity::find()
	.stream(self.get_connection())
	.await?
	.map(|res| Ok(res.map(Into::into)?)))
	}

This solution should fit for both the sequencer and the derivation pipeline, both consumers of the trait.

[Thegaram]

Are there any cases where we need to go back to an earlier L1 message, e.g. during reorgs? I guess the cursor pattern can better support that, though we can also just create a new iterator.

[greged93]

Are there any cases where we need to go back to an earlier L1 message, e.g. during reorgs?

Currently not, but we are still missing reorg handling in the derivation pipeline, although I don't think we would need to go back to an earlier L1 message during that process.

[frisitano]

Are there any cases where we need to go back to an earlier L1 message, e.g. during reorgs?

If we are operating in optimistic mode, where we include L1 messages after n blocks on L1, there is a chance we would need to revert back to an earlier L1 message when an L1 reorg that results in L2 reorg occurs. We handle setting the index in the sequencer for the reorg case here:

rollup-node/crates/manager/src/manager/mod.rs

Lines 272 to 277 in b8b4c6b

	// Update the [`Sequencer`] with the new L1 head info and queue index.
	if let Some(sequencer) = self.sequencer.as_mut() {
	sequencer.handle_reorg(queue_index, l1_block_number);
	}

This proposal for the new L1MessageProvider interface looks reasonable to me.