Avoid using MemBatch in ValidateChain

[Giulio2002]

We take advantage of sharedDoms

[Giulio2002]

this was useless btw

[Giulio2002]

had to move it here so that I can incorporate it with Flushing of domains

[AskAlexSharov]

I don't understand how ValidateChain can do BeginRw.
What if node does execution at this time?
It means we have less time for pruning?
What if you need validate 2 forks?
Or did you mean BeginRo?
Plz add this info in description of PR, otherwise hard to understand the intent.

[Giulio2002]

Ok, so the "Write" part of RwTx is only used for unwinding beforehand. If you look at the code the RwTx is rollbacked right after ValidatePayload. It does not mean we have less time for pruning. As a matter of fact, the flushing is done through SharedDomains and as you can see we keep it and use that to Flush, so functionally, it is as if we had diff like before but in the form of SharedDomain's writers. if you need to validate 2 big forks, you can do that with no issue, because it is functionally equivalent to the previous one.

Regarding intent, Intent are:

• to remove the FlushExtendingFork timing, before we were flushing domains on membatch and then flush membatch onto a RwTx, this was quite expensive in terms of performance
• Make the routine more stable, MemoryMutation is quite buggy, so it removes one of the things we have to worry about.

[awskii]

So this issue fixes DupSort issue in MemBatch causing
[5/7 Execution] ExecV3: loadIntoTable : fn error: prune history commitment got invalid txNum: found 2434374999 != 2433726825 wanted"

[Giulio2002]

yes that too, it is mostly a performance improvement though. removes 15ish% of block time. and also paves the way for persistence of some kind of cache across domains. maybe just the Btree