test: reset cucumber timeouts to practical limits

[hansieodendaal]

Description

Re-applied reasonable time outs to cucumber tests. It is not worthwhile
to have too stringent time outs as it makes the tests flaky on a slower
system and especially on CI.

Motivation and Context

Tests were flaky on slow and fast computers due to stringent time outs.

How Has This Been Tested?

Cucumber on slow and fast computers

[stringhandler]

Thanks for this, but it's going to be a nightmare if we keep going back and forward on these timeouts.

I suggest we do this:

1. create constants 'SLOW','FAST' and set the timeouts in the steps to use them
2. on CI, we set 'SLOW' = 60 seconds, FAST to 10 seconds using a world parameter, but by default they are set to 20 seconds, 1 second
3. Remove all custom timeouts and only use SLOW, MEDIUM, FAST,

Alternatively we can set it to 5 * seconds() and use a speed factor in the world parameters

[stringhandler]

this is too big a jump

[hansieodendaal]

Agreed, that one is not needed to be so high

[stringhandler]

20 minutes?

[hansieodendaal]

For stress tests

[hansieodendaal]

Thanks for this, but it's going to be a nightmare if we keep going back and forward on these timeouts.

I suggest we do this:

1. create constants 'SLOW','FAST' and set the timeouts in the steps to use them
2. on CI, we set 'SLOW' = 60 seconds, FAST to 10 seconds using a world parameter, but by default they are set to 20 seconds, 1 second
3. Remove all custom timeouts and only use SLOW, MEDIUM, FAST,

Alternatively we can set it to 5 * seconds() and use a speed factor in the world parameters

Let me think a bit about this and come up with a better solution than what we currently have. We have various value systems at play here; we do not want to wait a long time for a failing test, but we also do not want a test that will eventually succeed time out prematurely. This also behaves differently on slow and fast computers; the latter can many times be fixed with clever hold/synchronization points.

[stringhandler]

The CI passed using the previous values on #3494 and passed on 8 out of the 9 PR's following that (Github does not show circle ci results once it's merged, but I'm using the green and red ticks. They could have also failed on other checks. I'm excluding PRs to validator-node branch)

Given that 88% of the PR's passed, I would expect a far smaller adjustment to the timeouts

[stringhandler]

I think let's take this approach. As the tests fail, let's increase one or two steps at a time, as I have done in fad8520

[hansieodendaal]

Ok, will make small PRs for the failing tests.