[ETCM-856] make stSLoadTest pass

[AurelienRichez]

Note : this PR is currently using fix/ETCM-846-make-stBadOpcode-pass as base (#992) because it depends on it. I will change the target to develop when #992 is merged.

Description

This PR makes stSLoadTest pass. The was with the way we condifured hard fork transition in the tests :

• We set the default block number of a given fork to 0 when not specified, so a hard fork was active by default
• We did not recreate a new blockPreparator and blockGenerator so the new configuration was not applied in these.

I solved this by :

• By default, set the hard fork block to a high number if not specified (I chose Int.MaxNumber, but it is arbitrary)
• For hard forks which are not specified by ETS (basically ETC hard fork), I aligned their block number to an ETH one : We might want to check that these are adequate (but at least the test is passing).
• I changed some val to def to be sure the config

As an aside, I also deactivated upnp when running in testmode.

[jvdp]

Requesting changes because of the var.

[jvdp]

Is there any other way? I really feel we should avoid adding any more vars to the code base.

[AurelienRichez]

Well, I think we could replace TestLedgerWrapper with some utility class that provide a ledger and also a consensus implementation. We would still have a var somewhere but at least it would be more centralized. I will try something along those lines.

[jvdp]

Is thread safety a concern btw? This is essentially a shared resource right?

[AurelienRichez]

Not really. Clearly thread safety is not taken into account in the test service, but retesteth will run the test sequentially anway. There is a way to run tests in parallel but only with several instance of the client. But it wouldn't hurt to put the state in one place and put it behind an AtomicReference.

[jvdp]

Nice 👍 so the only mutable thing is now the timestamp? nvm, there's still the blockchain config var of course.

[dzajkowski]

the code is not passing scalastyle check

[AurelienRichez]

There is still some mutable state, but at least it's not scattered in several classes. TestService holds all the state and TestModeComponentsProvider actually take the "mutable" parts as arguments.

[leo-bogastry]

👍 Nice reorganization