Add the possibility for a plugin to validate a tx according to txpool rules

[fab-10]

PR description

This PR adds the new method

ValidationResult validateTransaction(Transaction transaction, boolean isLocal, boolean hasPriority);

to the TransactionPoolService interface, giving plugins the possibility to validate txs according to txpool rules, so that plugins implementing their own txpools can make sure incoming txs are valid.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[pinges]

Some comments

[pinges]

This sounds expensive for trying to find out whether that file is not empty. What about file.length()? I think it returns 0 if the file does not exist, so that might be all that you need to check for?

[fab-10]

You are right, changed.
I blindly consolidated more copies of this function, to remove code duplication, but I have not checked the implementation

[pinges]

There is only one key, so we do not need a number :-)

[fab-10]

done

[pinges]

s.a.

[fab-10]

done

[pinges]

Suggested change

	callbackDir = new File(System.getProperty("besu.plugins.dir", "plugins"));
	this.callbackDir = new File(System.getProperty("besu.plugins.dir", "plugins"));

[fab-10]

done

[relu91]

With different semantics it is already possible to filter transactions before they enter in the TxPool. In particular, after #8365, you can filter transactions using the permissioning API. As far as I can tell here we have a different goal, which is transaction validation rather than apply a policy (e.g. account X is not permitted to create a contract), but we have to explain to the end user the different pupose of these methods ane when to prefer one to the other.

Otherwise, we can explore a solution that works for both use cases.

[fab-10]

@relu91 I still need to review #8365, so I do not have the full picture yet, so I ca just add some context to help shaping the API

1 Scope of this PR is to expose the standard txpool validation done by Besu so that plugins can leverage it to implement custom txpools, delegating to Besu the standard txpool validation avoiding code duplication.
2 Besu plugins already have a way to extend the standard txpool validation via the PluginTransactionPoolValidator that is invoked here, we extensively use this approach to augment the txpool validation for the current requirement of Linea

So, if your requirement to extend the standard txpool validation, we can see how to merge it with the API listed at the 2nd point, otherwise if the requirement is to be able to validate according to standard rules txs that are not meant to be kept by the Besu txpool the the 1st point applies.