[Spike] Investigate better separation of private tx processing logic from public

[macfarla]

Review the branching of execution of public vs private transactions in an effort to better isolate their differences. The ideal scenario would be that, when running on public networks, none of the private tx logic would be ever in the code execution path.

See https://github.com/hyperledger/besu/issues/2606 for context

• [ ] add more tests that utilise chainId of 1 (mainnet) - need to make sure tests are totally isolated from Mainnet
• [ ] maybe we need a GoQuorumTransactionValidator - similar idea to GoQuorumBlockProcessor - instead of having code in MainnetTransactionValidator
• [ ] ensure sufficient testing - acceptance tests

Problem The scope of this problem is limited to: Value transfer public transactions received via JSON-RPC Value transfer public transactions received via DevP2P When receiving a value transfer tx via JSON-RPC, Besu was considering it a private tx and enforcing a validity check that prevents private transactions from transferring value. That's why it was returning the error message ether value is not supported for private transactions. When receiving value transfer tx via DevP2P, Besu was considering those transactions invalid, not propagating them further. Luckily, the logic for block validation and import wasn't using the same code path. This means that Besu would still successfully synchronise with Mainnet and be up-to-date. This bug won't cause a fork. It is worth mentioning that this bug was caused by a specific combination of factors, related to the chainId value being 1. Unfortunately, our tests do not cover scenarios with specific chainIds.

[vmichalik]

@macfarla @pinges @taccatisid can we brainstorm a few more things to be broken out of this?