BlockTransactionSelector refactoring

[Gabriel-Trintinalia]

PR description

BlockTransactionSelector refactoring:

• Extract TransactionSelectionResults to its own class.
• Extract Transaction Selection Criteria and selection logic out of the BlockTransactionSelector to their own classes
• BlockTransactionSelector will use a list of selectors to evaluate the transaction
• Similar to selectors that will evaluate a transaction

Next steps:

• Expose TransactionProcessingResult (or at least a part of it the to Plugin interface)
• Abstract the transaction selectors and external transaction selectors so they share the same logic
• Add a way to get the OperationTracer from the TPR and pass it to the plugin

[github-actions]

• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I thought about the changelog and included a changelog update if required.
• If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

[macfarla]

think it makes sense. would be good to get @fab-10 to take a look also

[macfarla]

is this a list because we're planning to add plugin factory here?

[Gabriel-Trintinalia]

yes, the next step is to change how we pass the factories to the block transaction selector

[fab-10]

I share the goal of the PR, since it adds more flexibility to the customization to the way we select txs for different use cases, I have some comments related to code readability, renaming to better express the intent of some methods, and trying to make it less error prone for future changes.

[macfarla]

ok with me