VM should use block height from state storage rather than block storage

[electricmonk]

There's a race condition in virtual machine that might cause reading from stale state. It is documented here:
orbs-network/orbs-network-go#400 (comment)

It's easy to prevent this race from happening.
In virtual machine, it currently takes the recent block height from state storage - see call to StateStorage.GetStateStorageBlockHeight().
We can change this call to be on block storage instead - BlockStorage.GetStateStorageBlockHeight().

[talkol]

We need to make the decision in the linked comment @OdedWx @erankirsh

[OdedWx]

Few comments:

1. Height from block storage implies that not updates state storage will hold (on a short race) / fail the call (on state storage not in sync)
2. Reading from the block storage on every call seams expensive in a a micro-service arch. In general the VM requires a high BW / low latency access to the state storage so this is likely to be solved while frequent access to the block storage is less intuitive.
3. Another approach which isn't too nice is to delay the TP update until the state storage acknowledges.

Let's discuss if we're willing to live with the race before adding the block storage to the call flow.

[talkol]

I was convinced by @OdedWx that we should keep the spec as is. Meaning keep the call to the state storage and not the block storage.

If we look at service affinity, the VM and SS are affiliated and communicate frequently. Adding a hot connection between VM and BS is a bad idea.

[electricmonk]

but this leaves the system in a non-deterministic state