Make network tests more resilient to origination time

[pasqu4le]

Clarification and motivation

Background

Our network tests have a slight complication over most others: the scenarios are written with the expectation that, after origination, they'll be at the beginning of the first period.

This wouldn't normally be the case however, because origination time take a while, so if we were to use "now" as the start of the first period we would have issues (especially in local-chain, where blocks appear more frequently).

Current solution

As a workaround to this problem we ended up using a delay in the "starting level" used at origination, so that when the next scenario "action" was executed it would be at the beginning of the first period.

This was done, in practice, by adding an offset in the stored starting level for the delay and then waiting to reach it.

Improvements needed

The current solution is somewhat brittle and more of a hack. The main problem being that the delay is somewhat arbitrary, because it needs to:

• be as short as possible, to avoid the unnecessary waiting times
• be as long, or longer, than the worst case scenario (aka the slowest origination).

These make the delay:

• hard to establish
• tuned to a specific protocol or tezos version (as we noticed with hangzhou's activation)
• never entirely safe, because origination can some times take longer due to external factors

So, we need to have a better system in place for this.

_note: some hints may be found in this slack thread_

Acceptance criteria

Network scenarios do not depend on contract origination time.

[pasqu4le]

Closing for the reasons explained in the PR