Revert "Shared domain merge"

[Giulio2002]

Trying to figure out why we have gas mismatch rarely and occasionally

[mh0lt]

Reverting this won't help. It is not the cuase of gas discrepancies they happen before this and just need to be investigared.

In general (I actually think 100% of the time) s related issues are cuased by logic errors in the IBS, or associated IO code cuased by an unexpected, unhandled edge case. So you need to determine where in the specific tx the problem is occuring to fix it. Obviously never say never, but I think this PR has macro level changes which don't affect the micro flow. Obviosly there may be some knowck on impact - but debugging the IBS + Instraction flow usually points directly to the problem, its just a case of gathereing the clues. Below id my normal method for doing this:

You need to analyse the flow. the tools for doing this are all availible in the dbg.Trace options.

This is what you need to do - expending on how reliable the gas mismatch is. I think the latest one sre deterministic:

1. When you get a gas mismatch you will see that the log output alreadu gives you the breakdown of the gas per TX.
2. Now you can work out which TX has the gas discrepancy by rerunning the TX on a working branch. For certaintly run it with TRACE_BLOCKS set tto the block where the discrepancy happens, you should also set TRACE_GAS which will dump you the gas per tx, and STOP_AFTER_BLOCK to the same block you are tracing.
3. Use text analysis to find the tx discrepancy (I use a combinatoin of linux tools + a spreasheet), there may be better ways but it takes a couple of mins uslly so I've not got around to improving this.
4. Whenou know which TX it is you can add the additional tracing options + ideally a debugger to find out what the specific problem is.

The useful ones are TRACE_TRANSACTION_IO and TRACE_INSTRUCTIONS - ususally a compination if these and a grep/text diff tool + the debugger will tell you where the issue is.

Reverting this I think just adds 2 additional already fix edge cases.

Note: The reason you need the STOP_AFTER_BLOCK is that generalluy the failing flow fails determinstrally - so you want to prevent the working flow (which should be working on the same db) from correcting the block anhence loosing the issue. If you have a non deterministic flow you will need a different strategy. Generally running with TRACE_GAS gives enough infor to guess what is going on - without adding so many timeing changes that the fail is hidden.