New sequence sender component

[ToniRamirezM]

Closes #2046

What does this PR do?

Reviewers

Main reviewers:

• @tclemos
• @Psykepro
• @agnusmor

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: ToniRamirezM.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[ToniRamirezM]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[tclemos]

I'm approving this PR because I don't see any blocker and I we want to add this feature in the next release.
The shared pool instance can create some side effects, please make sure we want to have this change.
The change to the default config makes sense to me, not sure if it makes sense to fix it now, if not, I recommend opening an issue to review this later.

[tclemos]

This change would force all the components running at the same binary to concur the db access. Multiple components will run different go routines but will consume a single pool Instance.

it's ok to initialize multiple pool instances for different components and the time it takes do instantiate shouldn't be a problem, I don't see a reason for this optimization and I'm afraid of the side effects it can cause when talking about concurrent and parallel executions to the pool.

What is the rational behind this change? Have you faced an issue during the development?

[ToniRamirezM]

I just thought it was better to just have one pool per binary. I can undo this is you don't feel confortable, or we are not sure if it may cause problems.

[tclemos]

Single pool, maybe better performance, maybe side cases.
Multiple pools, work as always, and already tests multiple times.

It's up to you, my suggestion is that we shouldn't touch on a team that's winning unless you want more emotion in your life 🤣

[tclemos]

Shouldn't this line be removed?
Even more, shouldn't we remove from the default config, values like addresses? We can keep them in the environment files.

[ToniRamirezM]

Yes, but maybe this is outside the scope of this PR. We should open a new issue in order to handle that.

[arnaubennassar]

txpool as a component is unused, you're using the error types but not the pool instance itself, note that:

type SequenceSender struct {
	cfg          Config
	pool         txPool
// ...

However in the code itself the pool (component) is not used, instead the package is used (txpool):

		if err == nil && tx.Size() > s.cfg.MaxTxSizeForL1 {
			metrics.SequencesOvesizedDataError()
			log.Infof("oversized Data on TX oldHash %s (txSize %d > 128KB)", tx.Hash(), tx.Size())
			err = txpool.ErrOversizedData
		}

and

func isDataForEthTxTooBig(err error) bool {
	return errors.Is(err, ethman.ErrGasRequiredExceedsAllowance) ||
		errors.Is(err, txpool.ErrOversizedData) ||
		errors.Is(err, ethman.ErrContentLengthTooLarge)
}

Apart from that, the need for the txpool itself is artificial, you're using a error type from that package that could be defined in this package, removing the dependency: err = txpool.ErrOversizedData